On Tue, 2 Jul 2013, Victor Yeo wrote: > > This looks like another bug in the UDC driver. It performs the Status > > stage of the Set-Config request before the gadget driver has finished > > carrying out the request. > > > > Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req() > > returns DELAYED_STATUS. As a result, fsg_setup() does not call > > ep0_queue(), and so usb_ep_queue() doesn't get called. The UDC driver > > is not supposed to ACK the Status stage of an OUT control transfer > > until usb_ep_queue() is called. > > May i verify my understanding of Set-Config request packet flow? > > Host Device > ------Setup Packet----> > ------Data0 Packet----> > <-----Ack Packet----- > > ------ In Packet ----> > <---- Data1 Packet ---- > ----- Ack Packet -----> > > ----- Out Packet ----> > ----- Data1 Packet ----> > <---- Ack Packet ----- No, that's not right. Set-Config has only two stages, Setup and Status; there is no Data stage. The flow is: Host Device ----- Setup Packet ---> | ----- Data0 Packet ---> |== Setup stage <---- Ack Packet ------ | ----- In Packet ------> | <---- Data1 Packet ---- |== Status stage ----- Ack Packet -----> | > "ACK the Status stage of an OUT control transfer", is it referring to > the Third ACK packet? So UDC driver should ACK only after Data1 packet > is sent via the usb_ep_queue()? I meant the Data1 packet above. The UDC driver should not send this packet until the gadget driver tells it to (by calling usb_ep_queue). Until then, it should send NAK in respond to the In packet. 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
