On Wed, 3 Jan 2007, David Brownell wrote:
> > > I'm presuming you mean "start the STATUS stage" ... which is not the same
> > > thing as sending an ACK.
> >
> > He meant "complete the STATUS stage". The host is responsible for
> > starting it, and the device responds with a 0-length DATA1 packet (not
> > an ACK).
>
> From the peripheral perspective, I'd call that "starting". The host is
> free to _ask_ the status stage to start, and both clearly agree when
> the DATA stage has completed. One could argue that the peripheral is
> just extending the status stage rather than refusing to "start" it, but
> for whatever reason I don't think about it that way very often.
Clearly this is nothing but semantics. My point of view is that of the
spec, which describes the STATUS stage as consisting of a single
transaction (or multiple transactions if the device NAKs). Hence it
begins with an IN or OUT packet sent by the host and ends with an ACK or a
STALL. But if you prefer to think it doesn't begin until the device sends
an ACK, a STALL, or a DATA1, that's okay.
> > This is slightly unfortunate. Section 8.5.3.1 of the USB spec states that
> > the DATA1 packet of a control-OUT STATUS stage shouldn't be sent until the
> > device has completed carrying out the request.
>
> Right, but that's easier said than done. The original goal was to have
> a usable programming interface to gadget programming ... not to capture
> every rare corner case of the USB spec. And the alternative would cause
> considerable hard-to-test complexity. (Read that as "be very bug-prone",
> "add weeks to implementation time", "be hard to maintain", etc.)
>
> And I'll note that the handful of protocols using control-OUT interpret
> that kind of loosely ... with the only one doing substantial work (the
> CDC "encapsulated command" mechanism) explicitly having the OUT part
> just a "deliver command", with separate mechanisms to report completion
> and return the results. In practice, restrictions here are not a big deal.
True enough. The only non-trivial case in g_file_storage is the same kind
of "completion only means command was delivered" thing, with no real
processing taking place until later.
> > But gadgetfs (and probably
> > the controller drivers too) won't wait; it will send the 0-length data
> > packet as soon as the OUT data has been received.
>
> For gadgetfs, that's correct ... the alternative being a significantly
> more complex (error prone) state machine, in what's already a way too
> complex and barely used code path.
>
> However, when the deferred response mode is not used, gadget drivers
> are supposed to be able to at least STALL in the completion callback
> for the OUT data. So they could report things like "invalid command"
> that way ... although, obviously, no more informative status.
Ah yes. In fact, there is a comment in net2280.c:
/* NOTE: net2280 could let gadget driver start the
* status stage later. since not all controllers let
* them control that, the api doesn't (yet) allow it.
*/
> > g_file_storage does use control-OUT transfers with non-empty DATA stages
> > when you run it using the CB or CBI transport (that's how each SCSI
> > command gets sent), but then it doesn't use a deferred response. And
> > g_file_storage does use a deferred response for the Bulk-Only Reset and
> > Set Configuration requests, but although they are control-OUT transfers
> > they don't have any DATA stages.
> >
> > So g_file_storage might not be the best test case for these questions.
>
> Exactly. But it does provide a pretty simple test for the main code
> path of deferred response mode (control-IN), which has been known to
> trip up controller drivers before. Once that works with a controller
> driver, most of gadgetfs should will behave too.
The main code path for deferred response mode used in g_file_storage is
not control-IN; it is control-OUT with no DATA stage. The most common
example is Set Configuration.
And that code path does indeed report errors by sending a STALL. Nobody
is likely to see such an event under normal circumstances, though --
errors in Set Configuration are awfully rare.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
