(Removed jinzhucheng -- "@tom.com" -- from CC list so this thread stops landing in my SPAM box...)
On Monday 23 January 2006 12:40 pm, Alan Stern wrote: > 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. ... > ... NAK indicates that > the function is still processing the command ... But that "still processing" is, in all "real world" cases we've identified thus far, easily defined as always false ... or at least, "usb_request.complete() hasn't yet returned". > Also, section 9.4.6 (Set Address) says: Clearly an "empty data stage" case. > 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. For zero-length data stages, that's already handled like any other "deferred" response. > > 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. Similar to the USB_CDC_SEND_ENCAPSULATED_COMMAND request, which has a non-empty OUT data stage. The processing is being defined as complete when usb_request.complete() returns. > Deferred response to the STATUS stage is my question. The Gadget API > doesn't seem to have any provision for supporting it at all. No, but as I pointed out there seems to be no need for it either; we don't have examples of protocols that need it, and we do have enough examples of hardware that can't support it that we want to be steering drivers away from wanting such things. (Even on the hardware which _could_ handle deferred ep0out status stages.) > 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. Well, other than having complete() take a long time; that's as I said. It can't be handed to a separate task, that's for sure. Note that deferring those responses would mean adding an asymmetry to the API: those ep0out transfers would call for drivers to queue TWO responses for one setup() call. And that would also embed a race you've commented on before: what happens if the host gives up and issues a new SETUP before the second 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. The "OP"? - 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
