On Tuesday 17 April 2007 2:23 pm, Laurent Pinchart wrote: > Hi everybody, > > I came across a device which exposes class specific interface descriptors > (CS_INTERFACE) that the current Linux kernel code can't parse. > > Most USB devices describe the class specific interface data between the > interface descriptor and its associated endpoint descriptors: > > INTERFACE > CS_INTERFACE > CS_INTERFACE > CS_INTERFACE > CS_INTERFACE > ENDPOINT 2 > > The device I'm trying to use returns the CS_INTERFACE descriptors after the > endpoint descriptors: > > INTERFACE > ENDPOINT 2 > CS_INTERFACE > CS_INTERFACE > CS_INTERFACE > CS_INTERFACE > > Is this legal ?
I'm not sure you'll find anything saying one way or another; check the relevant class device spec, those rules are actually class-specific. The "Common Class Specification" may be relevant for intent, too; but ISTR that's not normative with respect to what CS_INTERFACE means, it only defines a convention and encourages other specs to adopt it. > All examples found in USB specification documents put the > CS_INTERFACE descriptors between the INTERFACE and ENDPOINT descriptors, but > I found no mention of this being a requirement. > > The interface descriptor parsing code (usb_parse_interface in > drivers/usb/core/config.c) stores a pointer to those extra data in the struct > usb_host_interface 'extra' field. It currently only handles extra data > between INTERFACE and ENDPOINT descriptors. All descriptors after the > endpoint descriptors are just skipped. Not stored away as "extra" endpoint data? There's a field there to hold such stuff, and I was sure that it got used ... > Is this something we should fix ? If the extra data can be interleaved with > other descriptors, a single pointer won't be enough. It should be easy to set > the extra field to point to extra data after the endpoint descriptors, but it > won't work if class specific interface descriptors are interleaved with > endpoint descriptors. Actually, parsing of "extra" descriptors -- coupled to config, interface, or endpoint -- is the job of the driver. And I know that the usbnet infrastructure has had to cope with the evident inability of many implementors to read specs ... by adding workarounds that involve checking nonstandard locations for such class descriptors. So unless those extra descriptors are really getting discarded, I think usbcore is behaving OK. It can't really know what any descriptor not defined in the USB 2.0 spec means, so it can't go reshuffling them. Whereas drivers can know that they expect descriptors of a certain syntax, and incorporate workarounds for firmware (or even hardware!) bugs. - Dave > Best regards, > > Laurent Pinchart > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
