On Mon, 23 Jan 2006, David Brownell wrote: > On Monday 23 January 2006 9:17 am, Alan Stern wrote: > > On Mon, 23 Jan 2006, David Brownell wrote: > > > > The gadget driver only has to worry about telling the controller to > > > complete the request (by submitting a usb_request in response), or > > > stalling it (returning a fault code from the setup callback, or > > > later setting an explicit halt). > > > > > > One of the controller driver's responsibilities is to issue NAKs > > > until the gadget driver decides which of those responses to use. > > > > This was one of the things I never understood clearly: How does a gadget > > driver finish a control-OUT transfer? > > > > The gadget driver submits a usb_request for the OUT data, and the > > completion handler for that request gets called when the data arrives. > > Right. This is something that not all hardware -- and not all > controller drivers -- handles quite the same way. > > The main nonportability comes if the gadget driver wants to STALL > that request ... e.g. "I see this host request, but it's nonsense > that I can't handle". Most protocols don't expect to be able to > stall at that point, which is fortunate. > > A secondary nonportability comes if the gadget driver wants to try > using "deferred response" mode for that OUT DATA segment ... that > is, return zero from the setup() callback and issue the usb_request > to collect the data sometime later. Again, not all hardware allows > that (sometimes acking the SETUP implies acking subsequent OUT DATA > transfers), and even if it does allow it there may be misbehavior > if the fifo gets filled before the usb_request gets queued. (Look > at the at91_udc code for one example. The "fifo filled" IRQ is > only cleared by emptying it -- to a buffer that may not yet be > available! -- but it must be cleared in order to handle SETUP.)
Okay, more or less as I expected. But that wasn't really what I was asking about. > > How then does the gadget driver tell the controller driver that the data > > has been processed successfully and it's okay to ACK the host's > > status-stage IN packet? By submitting another, zero-length usb_request? > > file_storage.c doesn't ever do that, but net2280 sends the ACK packet > > anyway. > > The completion handler for that OUT transfer has two options. > One is easy: do nothing, that means the status stage can ACK. > > Alternatively, set the ep0 halt feature and stall the status > stage. That's the part that not all hardware handles (some > can't physically issue a STALL at that point) and not all > drivers handle (it might help if there were a test case that > exercised this case). Thus the OUT-data completion handler can signal immediate success or immediate failure. The problem is that the gadget isn't supposed to respond until command processing is complete, which implies a deferred response. > For portability, don't expect to stall the ep0out status > stages ... and always issue the usb_request for that data > stage before returning from the setup() callback. > > As I recall, net2280 is one of the few controllers that lets > these cases be handled in any way the gadget driver needs. > Most others -- presumably because control-OUT transfers are > rare outside of RNDIS -- have restrictions there. And apparently none of them support deferred response in the status stage. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
