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
