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. 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. 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... > My first guess was to send a zero-byte write, but looking at the > example gadgetfs program (http://www.linux-usb.org/gadget/usb.c), the > only control out transactions that it handles are SET_CONFIGURATION and > SET_INTERFACE, and it acks these with a zero-byte read: > > /* ... ack (a write would stall) */ > status = read (fd, &status, 0); Right. That example program doesn't do control OUT transfers. Those two requests are kind of special, since they have no data stage ... the zero byte read is used because those requests are in protocol terms "OUT" transfers with (surprise!) no data bytes. Note that since an OUT transfer should normally be handled by a read() then processing the data, a write() response to an OUT request is used to mean "please stall this request". Contrariwise, since IN transfers should be handled by a write() of the requested data, a read() stalls that type of response. (No ioctls needed!) > This does indeed work in these cases, but I have tried doing it for > other control out transactions (i.e. type=vendor), where as far as I > can see it doesn't work; the host never sees the ack and eventually > times out. But are those zero length requests? The low level code doesn't care a thing about "type=vendor". It looks at direction (IN vs OUT) and length (zero vs more). > There's a good chance that I'm doing something stupid, but > I'd like to understand whether I really should be doing reads or > whether this is a special case for these particular control > transactions. When I try doing a zero-byte write for the type=vendor > transactions I get "Level 2 halted" (EL2HLT), which I suspect is the > "write would stall" that the comment in usb.c is alluding to. Are those IN transfers? If so, writes mean "please stall". - 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
