Hi Alan, Even though the solution of sending the ack only after set_config return seems to be working, the real issue is, What if two function drivers want to wait on DELAYED_STATUS in a composite framework? Which driver of the two should send the ack? If we decide, to send from a particular function driver, how do we ensure that the particular driver(which send the ack) return from set_config after the other driver? Can, you, please suggest me ? Thanks, Chiru. On Thu, Aug 13, 2009 at 6:17 PM, velempati Chiranjeevi<velem.usb@xxxxxxxxx> wrote: > Thanks Alan, > > I shall implement the solution & get back. > > Controller is ChipIdea. > > Thanks, > Chiru. > > On Wed, Aug 12, 2009 at 8:02 PM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: >> 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
