On Sun, 9 May 2004, Heiko Rosemann wrote:
But, if you get another SETUP request and just by bad luck the data registers are still set up for an IN request with previous data, you easily get the wrong data if you send the IN request before the controller can handle the setup-token-IRQ.
That would be an example of a hardware design bug, FWIW ... receipt of the SETUP data should have flushed all the other ep0 state. As you imply, there's no way to guarantee that software can ever do that in time to prevent problems. Or maybe it's a chip erratum.
One example: If you read data (e.g. for a descriptor read), you read it in multiples of the endpoint buffer size. If you do a full read (i.e. read as many bytes as the device sends out), the device just sends data until there is none available anymore, ending with a packet of 0-7 bytes if the endpoint buffer length is 8 bytes. If you do a short read (i.e. read less data than the full descriptor), you are not allowed to end the read with a 0 byte-packet, but instead you have to end with a packet of 1-8 bytes. Don't
You're saying some of these devices expect an extra IN from the host, retrieving a zero byte packet, AND have a bug wherein they don't start the status stage correctly (sending an OUT with zero bytes)? That'd be in addition to the "not clearing state when SETUP is received".
ask me why, with Windows, you don't have that limitation. And I didn't find any information about this particular matter in the USB specs either.
Just for your information,
Heiko
That's a nice analysis, although perhaps things aren't quite as bad as you indicate since there will be an OUT packet that has to be acknowledged before the next SETUP packet is sent.
More to the point, do you have any recommendations for how the host should try to cope with this sort of problem?
I think the implication is that sending an extra ZLP-in at the end of all descriptor fetches (modifying all HCDs!) would make such buggy devices behave better. Thing is, when I've tried that, I've seen other devcies misbehave in other ways.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
