On Mon, 10 May 2004, David Brownell wrote:
> Alan Stern wrote:
> > 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.
The documentation is not really clear about this - but this would at least
explain some of my problems I was having. (I am using a Motorola
68HC908LD64, FYI)
> >>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".
Well, I had to make the device send an empty extra IN packet, if, and only
if Linux is doing a read of the full descriptor. If linux only reads the
first 8 bytes, the device is not allowed to send an empty extra IN, which
does work with Windows.
> > 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.
Nope. If I was reading the documentation correctly, the host can send a
SETUP packet anytime it feels like doing it, and the device has to cancel
all other transfers on the reception of a SETUP packet.
> > 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.
I'm not proposing any changes, I finally made my device work, so I'm fine
with the 2.4 and the 2.6 USB implementation of Linux. I was just jumping in
to give a short explanation to what the first posting was asking.
And yes, Windows is expecting an additional ZLP-IN after fetching the
descriptor, if the descriptor length is a multiple of 8 bytes. Don't know if
Windows ever tries to read only the first 8 bytes, which is what Linux was
having trouble with.
Regards, Heiko
--
* WARNING! The USB documentation is downright evil. Most of it
* is just crap, written by a committee. You're better off ignoring
* most of it, the important stuff is: [...]
-- 2.4.24's drivers/usb/host/uhci.c (full ack!)
-------------------------------------------------------
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
