> 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.
IFF the descriptor length matches the bytes received it may be reasonable to accept it as valid data. Does this device enumerate properly against Windows? If Windows accepts it then we pretty much have to as well. It is unlikely that this device works against the USB org validation suite, but for most consumers working with Windows is the only test that counts. -- [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
