David:
This probably resembles a question I asked before, but I'll ask it again just for kicks.
Yes, but it provides a different context ...
The USB Mass Storage Class CBI Transport Specification includes this paragraph:
------------------
2.4.2.5 Data In: Host Requests Too Many Bytes
If the host sends more IN PID than the device can satisy, then the device may NAK indefinitely (for more information, see section 2.3.2.4). The device should STALL (see section 2.4.3).
------------------
2.3.2.4 talks about the interrupt/status endpoint, saying it will NAK until the command completes. So completion of the status transfer might indicate a host side error, when there are requests still queued and the requests aren't just completing in an unexpected order. (They're on two different queues, so of course completion order can vary.)
2.4.3 says it'd be a real endpoint halt. In short, it's another way to report this same host-side error.
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.
Would queueing a 0-length bulk-in request and halting the endpoint within
the completion routine do the trick? Or would the hardware simply ACK the transfer, meaning the host wouldn't see a STALL until the _next_ packet?
That would transfer a ZLP. Sometimes (2.4.2.1) that'll be part of the normal transfer protocol ... req->zero should be handle that, when the device intends to return less data than the host requested.
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.
- Dave
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
