Dear Experts,
I have a simple test program that will try to read e.g. a device
descriptor using ioctl(USBDEVFS_CONTROL). I've been trying this with
my assorted USB devices, with an analyser hooked up, and it's
remarkable how even something as basic as this can break some
non-compliant devices.
When a full-speed device is attached, the kernel first tries a 64-byte
read of the device descriptor. If the device has an 8-byte ep0 max
packet size, it will return the first 8 bytes of the descriptor; the
host immediately does the status stage.
Later it reads the device descriptor with an 18-byte read and gets the
data in 3 packets (8+8+2).
If I read the descriptor using USBDEVFS_CONTROL, I'll also get the 18
bytes in 3 packets. With most devices I'll get the same behaviour if I
ask for 18 bytes or if I ask for 64 bytes. However, if I ask my
printer for 64 bytes it will return the first 8 and then NAK until the
host times out.
I presume that my printer is not allowed to do this: it should return
18 bytes in 3 packets, and the host should realise that the data is
complete after the short 2-byte packet and do the status stage. It's
yet another device that's somewhat non-compliant, right? But what I
don't understand is why the kernel's initial 64-byte read and my
64-byte read behave differently (and not just on this broken device):
why does the host controller consider the data complete and send the
status stage after one packet of 8 bytes when the kernel does it, but
keep sending INs (which are NAKed) when I do it?
Can anyone explain what's going on? I'm curious because I fear that
there's another layer of complexity hiding in there, e.g. some
additional state that changes the host controller behaviour, that I
have yet to understand.
Many thanks,
Phil.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
