On Mon, 23 Jan 2006, David Brownell wrote: > > 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. > > That "supposed to" isn't accurate. Maybe in some protocols, > but I've never seen one. (Talking purely about Control-OUT > transfers with non-empty data stages.)
I was speaking of the requirements in the USB spec. Section 8.5.3.1 says: For control writes, the host sends an IN token to the control pipe to initiate the Status stage. The function responds with either a handshake or a zero-length data packet to indicate its current status. NAK indicates that the function is still processing the command and that the host should continue the Status stage; return of a zero-length packet indicates normal completion of the command; and STALL indicates that the function cannot complete the command. Also, section 9.4.6 (Set Address) says: Stages after the initial Setup packet assume the same device address as the Setup packet. The USB device does not change its device address until after the Status stage of this request is completed successfully. Note that this is a difference between this request and all other requests. For all other requests, the operation indicated must be completed before the Status stage. The implication is clear: Except for Set-Address requests, the status stage is not supposed to finish until the request has been carried out. So in principle, a deferred status-stage response may be needed. > If you consider for example the CDC "encapsulated request" mechanism > (which FWIW is the only mechanism I recall seeing written up that > relies on non-empty ep0out data transfers, once you discount things > like SET_DESCRIPTOR which seem to never get implemented), that's untrue. There's something like it in the Mass Storage CB protocol; SCSI commands are encapsulated in control-OUT transfers. Of course, in this case the request processing is complete as soon as the gadget has received (and understood? -- unclear) the SCSI command, not when the SCSI command has been executed. > > And apparently none of them support deferred response in the status stage. > > For ep0in, or ep0out-no-data, that notion is meaningless ... issuing > the usb_request explicitly permits the status stage to complete > whenever the host wants it to. Right. I'm talking about control-OUT with data. > Any driver that behaves right with > your g_file_storage driver(*) necessarily handles deferred response > for the DATA stage. Deferred response to the STATUS stage is my question. The Gadget API doesn't seem to have any provision for supporting it at all. Either the data stage completion handler halts ep0 to send a status-stage STALL (not supported by all controller drivers) or it doesn't, in which case the controller driver sends a status-stage zero-length packet immediately. There's no way to defer the status-stage response. I don't know of any drivers that _need_ these deferred responses. This was a theoretical question, prompted by some questions from the OP. 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