Again, seems like NAK is the answer. And the way to make the gadget stop NAKing is to provide some data for it to deliver to the host: submit a request to that IN endpoint, with its data buffer.
If a STALL is the right response, then halt the endpoint. Otherwise the only non-error responses are to NAK, or to provide the requested DATA.
What if STALL is only temporarily the right response? That is, the gadget doesn't have any more data to send until the host gives it another command. If the host tries to read more data, it should receive a STALL.
So far as I understand, that's not part of the USB device model.
What happens if the host has sent all the data the gadget driver wants, and is still sending more, has filled the FIFO, and is continuing to send data? It will wait while the gadget NAKs. But the gadget driver won't know what's going on and hence won't be able to HALT the endpoint, thereby telling the host that the gadget won't accept any more.
If the host is sending more data, and the gadget driver doesn't expect it, that's clearly a protocol error. (While it's true that STALL generally means there's an error, that's not the only kind of error...)
Probably the only answer to these problems will be to let the host timeout the transfer.
Yes. In fact, having a FIFO there doesn't affect that answer at all. In both cases (IN, OUT), this is a host side protocol error, with the only real fix being to get rid of that host side bug.
- Dave
------------------------------------------------------- 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
