Hi, >> Yes, this should be the root cause. For the setup stage of Set-Config >> request, the UDC driver can handle it well. But for the status stage >> of Set-Config request, somehow it is not handled correctly. When UDC >> driver receives the endpoint 0 IN token, it only clears the interrupt >> request. It will not send the Data1 packet unless usb_ep_queue() is >> called. > > And yet it _does_ send the packet before usb_ep_queue() is called. I am still studying how Data1 packet is sent out, from the log, usb_ep_queue() is not called, i have no idea now. > DELAYED_STATUS tells fsg_setup() not to call ep0_queue(). It means > that the request isn't finished yet, so the status isn't known. The > status will be reported later, when the request is finished. > > handle_exception() is used for things that cannot be carried out in > interrupt context. fsg_setup() runs in an interrupt handler, so it > can't call do_set_config() or do_set_interface() -- those routines need > to run in process context. Therefore the USB_REQ_SET_CONFIGURATION > code raises an exception; when the fsg thread handles the exception, it > calls do_set_config(). May i know which part of the do_set_config() or do_set_interface() has to be run in process context? Thanks, Victor -- 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
