Re: Class specific interface descriptors parsing issue

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel