AnsweredAssumed Answered

More anomalous code fragments in the USB 5.0 stack

Question asked by John Strohm on Jan 15, 2015
Latest reply on Jan 19, 2015 by Kan_Li

This shows up in several places, most severely in usb_phdc.c, at lines 844-849.

    devicePtr->user_handle = *phdcHandle;

 

    #if USB_METADATA_SUPPORTED  

    devicePtr->phdc_metadata = FALSE; /* metadata feature disabled */

    #endif

    *phdcHandle =(unsigned long)devicePtr;

 

phdcHandle is described as an OUT parameter, meaning that it points SOMEWHERE valid, but the contents are unlikely to be anything useful.  This means that the assignment at line 844 is likely to store garbage in a well-defined place.

 

If the two assignments are reversed in order, garbage is not stored.  Instead, devicePtr->user_handle points to itself, which does not seem particularly useful, since you would then have devicePtr->user_handle == devicePtr.

 

usb_hid.c has the assignments in reverse order, viz.,

    *hidHandle =(unsigned long)devicePtr;

    //devicePtr->user_handle = *hidHandle;

but the self-looper creation is commented out.

 

usb_audio.c has the assignments in reverse order, making the self-looper.

    *audioHandle =(uint32_t)devicePtr;

    devicePtr->user_handle = *audioHandle;

 

The other class drivers all define a user_handle field in their respective header files, but do not bother to assign anything to it.

 

This looks like something that could be cleaned up.

Outcomes