> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Phil Endecott
> Sent: 2007 December 13 18:59
> To: [email protected]
> Subject: Initial device descriptor read size
>
> 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.
The most logical approach I've seen is to do a first read of the
Device Descriptor, of only 8 bytes. This gets you two crucial pieces
of information: (1) how big the descriptor is in total, and (2) the
maximum packet size. Armed with this information, you can now do a
second read of the full descriptor. The first read, at only 8 bytes,
can't be faulted.
Dave
*************************************************************************************************************************************************************************************************************************************************
NICE CTI Systems UK Limited ("NICE") is registered in England under company
number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End,
Southampton, Hampshire SO30 2ZP.
Confidentiality: This communication and any attachments are intended for the
above-named persons only and may be confidential and/or legally privileged. Any
opinions expressed in this communication are not necessarily those of NICE. If
this communication has come to you in error you must take no action based on
it, nor must you copy or show it to anyone; please delete/destroy and inform
the sender by e-mail immediately.
Monitoring: NICE may monitor incoming and outgoing e-mails.
Viruses: Although we have taken steps toward ensuring that this e-mail and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.
****************************************************************************************************************************************************************************************************************************************************
-
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
