On Thu, 21 Aug 2003, David Brownell wrote:
For OUT, it's an error if the controller sees more OUT bytes than the queued request allows. The controller driver should automatically stall, reporting -EOVERFLOW.
Really? The USB 2.0 spec says (section 8.4.6.3):
If the function cannot accept the data packet due to flow control reasons, it returns NAK.
See also Table 8.6. There's nothing about STALLing in response to an unexpectedly large packet.
It's not flow control; it's an error, the two sides disagreed on the transfer size. STALL is fundamentally an error indicator.
I can't read 8.4.6 as talking about control transfers, since it's assuming a streamed transfer (bulk/interrupt/iso) and doesn't include any cases where IN follows OUT (or vice versa).
On the other hand, 8.5.3 is explicit about control transfers, and says (bottom of p. 227) to send a STALL when the data stage is too big (IN or OUT).
- Dave
The same sort of reasoning applies to unexpectedly large IN transfers. The host returns -EOVERFLOW status in the URB, but it is not allowed to send anything other than ACK to the device (8.4.6.2 and Table 8.5). So the gadget's request should not return -EOVERFLOW status (as dummy_hcd does).
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
