Hi David, > > 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.
The UVC specification doesn't clearly state if the sample descriptors order is required or not. I asked on the USB-IF compliance forum. > > 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 ... Oops, I had forgotten about extra endpoint data :-/ Thanks. > > 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. Thanks for your help. I'll have a look at the extra endpoint data. Seems I'll have to fix my driver instead of complaining here ;-) 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
