On Wed, 8 Feb 2012, Steve Calfee wrote: > 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. I concur with everything you say. The ACKs we have been talking about are the responses to the SETUP packets, the ones which have to be sent within a few bit clocks. > If the software gets a second SETUP before the first has completed, > most likely a transfer error occured and things are going bad. Indeed -- or possibly the host didn't receive the ACK for the first SETUP packet and has resent it. > The > host timeout for SETUP packets You mean the timeout for control transfers, not SETUP packets. > should be on the order of seconds - "should be" ... but might not be. > which should be enough for the gadget to get its endpoints ready. It's true that in normal operation we will not have to worry about this race. Nevertheless, drivers should be written to handle even edge cases and unlikely races correctly. 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
