Hello people,
continueing my fight with DWC OTG controller I'm now pretty sure I've
found a place exactly related to why g_file_storage DOES work whereas
g_serial does NOT. Sorry for my ignorance, but could someone please
explain the meaning of the lengthy confused comment in code fragment
listed below, and does the assumptions implied there even apply
nowadays? (The code was targeted for 2.6.22 and earlier, so it is quite
ancient and AFAIK it was not revised much since)
Thank you.
Nikolai
/**
* This functions delegates the setup command to the gadget driver.
*/
static inline void do_gadget_setup(dwc_otg_pcd_t *pcd,
struct usb_ctrlrequest * ctrl)
{
int ret = 0;
if (pcd->driver && pcd->driver->setup) {
SPIN_UNLOCK(&pcd->lock);
ret = pcd->driver->setup(&pcd->gadget, ctrl);
SPIN_LOCK(&pcd->lock);
if (ret < 0) {
ep0_do_stall(pcd, ret);
}
/** @todo This is a g_file_storage gadget driver specific
* workaround: a DELAYED_STATUS result from the fsg_setup
* routine will result in the gadget queueing a EP0 IN status
* phase for a two-stage control transfer. Exactly the same as
* a SET_CONFIGURATION/SET_INTERFACE except that this is a class
* specific request. Need a generic way to know when the gadget
* driver will queue the status phase. Can we assume when we
* call the gadget driver setup() function that it will always
* queue and require the following flag? Need to look into
* this.
*/
if (ret == 256 + 999) {
pcd->request_config = 1;
}
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
