On Wed, Feb 8, 2012 at 9:53 AM, Paul Zimmerman <Paul.Zimmerman@xxxxxxxxxxxx> wrote: >> -----Original Message----- >> From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern >> Sent: Wednesday, February 08, 2012 7:30 AM >> >> On Wed, 8 Feb 2012, Sebastian Andrzej Siewior wrote: > > < snip > > >> > Receiving another SETUP packet while handling the current one isn't >> > possible at least on dwc3: Lets say SET_INTERFACE will be delayed. The >> > controller probably acks it immediately. The only thing the driver does >> > is to setup the next transfer to receive another SETUP packet. Right >> > now we delay this step until gadget is done with his SET_INTERFACE. If >> > we don't, we have another setup packet waiting for us (that one after >> > SET_INTERFACE). I don't have an USB sniffer to say that this is what >> > really happens, but it looks like it from the driver perspective. >> >> That doesn't sound like quite the right approach. A USB device is >> always supposed to accept SETUP packets. What the driver needs to do >> is keep track of them, and not give the response for an earlier SETUP >> to the hardware after a later SETUP arrives. Cases where the two >> things happen simultaneously must be handled by the hardware. > > I can verify that Alan is correct here. If the EP0 OUT endpoint is > enabled, the dwc3 controller will always accept and ACK a SETUP > packet. Up to 3 SETUP packets can be held internally in the hardware, > any more than that will be discarded (but still ACKed). The driver > will receive the next queued SETUP packet the next time it starts a > transfer on that endpoint. > > -- > Paul Hi All, Alan is correct, but the whole discussion is confusing acks. The hardware has to respond to packets in a few bit clocks. However all setup packets (see section 5.5.5 in usb 2.0 spec) are followed by zero or more data packets as required. These can be naked by the gadget hardware until the software prepares it to receive more data. After all optional data packets have been passed, a final "opposite" direction zero length IN or OUT transaction is sent. Again the hardware can NAK this for a long time until the software finally does whatever the SETUP packet asked - some of which can take a long time (like set interface). When the gadget is all done and ready for new SETUP packets the gadget software will enable the response to the zero length packet with a software ACK. If the hardware does not allow the software to sequence that final zero length packet (see section 8.5.3.1), there will be problems. For example, say the host changes the alt/interface. What should happen is the gadget will enable the required endpoints, then signal completion by enabling the zero length status packet so the host knows it is ready. If this ack is done automatically there is a race between the host sending data on one of the newly enabled endpoints and the gadget getting the endpoint enabled enough to NAK until the gadget is ready. Also, only the gadget software knows if this final zero length status packet should be responded to by a stall telling the host that something is seriously wrong. If the software gets a second SETUP before the first has completed, most likely a transfer error occured and things are going bad. The host timeout for SETUP packets should be on the order of seconds - which should be enough for the gadget to get its endpoints ready. Regards, Steve -- 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
