I've got a device (production model, not that new) which
seems to be acting strangely when usb.c requests a string
descriptor. The way it's supposed to act is defined in the
USB 2.0 spec, section 9.4.3:
If the descriptor is shorter than the wLength field, the
device indicates the end of the control transfer by
sending a short packet when further data is requested.
Now, the descriptor happens to be 40 bytes long, and
the control endpoint has maxpacket size of 8 bytes.
Since 255 bytes are requested, what should happen is:
SETUP
DATA ... 5 packets, plus one zero length
ACK
It's not sending the zero length packet. Device is clearly
non-conformant. The control request stalls out, but does
indicate that it got all 40 bytes ... which usb.c discards.
Does anyone think it'd be bad to update the descriptor
access code to recognize such cases? We have code
to work around other conformance bugs. I'm inclined to
do it for this one too, and make usb_get_string() use
generic usb_get_descriptor() code that does so.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
