On Wednesday 03 January 2007 9:46 am, Alan Stern wrote: > On Wed, 3 Jan 2007, David Brownell wrote: > > > On Tuesday 02 January 2007 4:35 am, Phil Endecott wrote: > > > Dear All, > > > > > > How should a gadgetfs application cause an ACK to be sent to the host > > > in response to a sucessfully received and processed control out > > > transaction? > > > > 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. > > The controller acks automatically, and then after > > the last DATA stage packet is sent, the STATUS stage is a packet going the > > other direction. Until the STATUS stage is acked, the control transfer has > > not completed. > > > > Modulo hardware interface botches which will in at least one case (AT91) > > preclude this for gadgetfs, the status stage should start automatically > > when all the data has been read. So: issue a read (this is OUT) for > > N (>0) bytes, and the underlying controller driver should automatically > > start the STATUS stage of the control transfer. > > 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. > 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. > > Something to be aware of: not all gadget controller drivers seem to > > handle control-OUT transfers correctly ... especially in the "deferred > > response" mode needed by gadgetfs. You can test control-OUT transfers > > using "usbtest" test case #14; and g_file_storage uses deferred response > > mode, but ISTR not for control-OUT transfers. You might be hitting a > > controller driver (or controller!) bug specific to that combination... > > 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. - Dave ------------------------------------------------------------------------- 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
