On Monday 23 January 2006 10:49 am, Alan Stern wrote: > > The completion handler for that OUT transfer has two options. > > One is easy: do nothing, that means the status stage can ACK. > > > > Alternatively, set the ep0 halt feature and stall the status > > stage. That's the part that not all hardware handles (some > > can't physically issue a STALL at that point) and not all > > drivers handle (it might help if there were a test case that > > exercised this case). > > 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.) 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. > > For portability, don't expect to stall the ep0out status > > stages ... and always issue the usb_request for that data > > stage before returning from the setup() callback. > > > > As I recall, net2280 is one of the few controllers that lets > > these cases be handled in any way the gadget driver needs. > > Most others -- presumably because control-OUT transfers are > > rare outside of RNDIS -- have restrictions there. > > 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. Any driver that behaves right with your g_file_storage driver(*) necessarily handles deferred response for the DATA stage. For ep0out-with-data, more hardware _could_ support that, but as I'd commented earlier, the test suite doesn't cover that. - 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
