On Sat, 16 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > > Granted that the indefinite NAK is most likely the way I'll go, > > nevertheless how would the Gadget API support the STALL alternative? > > Bear in mind that this STALL is _not_ supposed to happen if the host > > doesn't request too much IN data. > > The API doesn't support it now; I think of it as a hardware-specific > capability. Even PIO-oriented controllers won't necessarily expose > those NAKs (say, by IRQ or a pollable status bit). If the hardware > exposes it, a gadget driver callback could be made to work. > > I'd prototype it as a controller-specific API, then maybe move into > the main API if it turns out to be important.
So it's not feasible at the moment. That's fine. > Would it work if you always halted the IN endpoint after a transfer? > I thought I saw indications that the host was supposed to clear halts > in such cases. That would of course slow down data transfers. You must be thinking of section 2.4.3.1.3, where the specification says: A device may STALL the Bulk In pipe AFTER the last data has transferred. For this reason the host shall also issue Clear Feature for Endpoint Halt to the Bulk In pipe if the device reports that the Data In command block has Failed. So one wouldn't want to halt the endpoint in general. (Come to think of it, I believe the usb-storage driver doesn't issue the Clear Halt under those circumstances. While this lack doesn't seem to have hurt anything, maybe it should be added in.) Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
