Heiko Rosemann wrote:
On Mon, 10 May 2004, David Brownell wrote:
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.
Sounds like a hardware quirk -- is it actually sending that IN,
or are you just setting it up? I could easily imagine hardware
that doesn't enable STATUS stages until a ZLP is queued, and as
you've observed Linux doesn't actually ask for the ZLP.
The USB spec says (5.5.3):
The Data stage of a control transfer from an endpoint to the host
is complete when the endpoint does one of the following:
- Has transferred exactly the amount of data specified during
the Setup stage
- Transfers a packet with a payload size less than wMaxPacketSize
or transfers a zero-length packet
When a Data stage is complete, the Host Controller advances to
the Status stage instead of continuing on with another data
transaction. If the Host Controller does not advance to the Status
stage when the Data stage is complete, the endpoint halts the pipe...
And 8.5.3.1 agrees, saying a STALL "should" be sent when the host
asks for more data than specified in the setup stage. (As with a
ZLP IN.)
Sounds like Windows would misbehave with strictly-conforming devices
that halt the control endpoint rather than sending a needless ZLP-IN.
(IMO halt/stall is a bad interop answer; sending or receiving a ZLP
should be simple and harmless. That's what I've done with the
device controller drivers I've worked on.)
Hosts requiring ZLPs to terminate control DATA stages are clearly not
conformant to USB, but I could believe that there are devices that
only talk to such hosts. (Because of firmware or hardware issues.)
Leaving Linux a dilemma ... issuing ZLPs fails with USB conformant
devices, but not issuing them evidently breaks others. Sigh.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
