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.) > 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). 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. - Dave ------------------------------------------------------- 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
