On Wed, 12 Aug 2009, velempati Chiranjeevi wrote: > Hi, > > I figured the actual cause of the issue.But I am not sure about the > implementation of the solution. > > > In the gadget framework, When the host sends the set_config command, > the set_alt of all the functions are called. > > In the mass storage , the set_alt function raises an exception and > returns 0.The endpoints are enabled as part of the do_set_config, > triggered the handle_exception. But by the time the endpoints > corresponding to mass storage are enabled, we get a command from the > host as a part of the USB MS CV test.Since the endpoints are not > enabled by now, the UDC driver doesn't send an ack. So the test fails. > > > Can the endpoints be enabled as part of the interrupt context ? I don't think so. But it doesn't matter, because that's not the real problem. The cause of the failure is that the host sends a command before the Set-Config has finished. Assuming that the host is working okay, this means the device controller completes the status stage of the Set-Config request before the endpoints have been enabled, i.e., before do_set_config() returns. However, if you look at standard_setup_req() in file_storage.c, you'll see that the USB_REQ_SET_CONFIGURATION case sets value to DELAYED_STATUS. This means that fsg_setup() won't call ep0_queue(). Now, the device controller driver is supposed to delay the status stage of a control transfer until an explicit response is queued for ep0. (See the kerneldoc description of control endpoints under usb_ep_queue() in include/linux/usb/gadget.h.) That response is queued by handle_exception() in the FSG_STATE_CONFIG_CHANGE case, where the code calls ep0_queue() after do_set_config() returns. Hence the real problem lies in the device controller driver, not in g_file_storage. The driver carries out the status stage before it is supposed to. You didn't say which controller driver you are using, so I can't tell you how to fix it. Alan Stern -- 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
