On Wed, 3 Sep 2003, David Brownell wrote:

> There are devices that send interface descriptors in other orders.
> For example, the AMBIT USB Cable modem passes interface 1 then 0.

Okay.  So this really is something we have to watch out for.

> The only reason I've been able to come up with preventing config.c from
> reordering these is that some devices could be broken enough to break
> the rule that N interfaces have are numbered 0..(N-1) ... in which
> case the array indexing model wouldn't work.  (We know it fails for
> configurations, since the configuration numbers aren't designed to
> be indexes; a single config could be numbered 255 for example.)

In my opinion, config.c definitely should check for that.  It should also
check that the altsettings are numbered 0..(M-1) and that all the
altsetting descriptors for an interface have the same bInterfaceNumber.  
Rather than ruling out entirely devices that break these rules, maybe we
can mark some of the interface entries as "bad" so the core doesn't try to
use them.

It wouldn't hurt to check for a few other things as well, like endpoint 
numbers not in the 1..15 range.

> You're right.  I may be at fault for some of that text asserting they're
> ordered.  But right now it's clear there's nothing enforcing an order,
> so it seems to me that all code should be using an accessor function
> that knows how to cope with out-of-order config, interface, altsetting,
> or endpoint descriptors ...

Hmm...  There already are accessor functions for interfaces and endpoints,
although they aren't necessarily used correctly or consistently in all
places.  There isn't an accessor for configurations, but I think
usb_set_configuration() is about the only place that would use it.  
(Maybe something in usbfs could use it too.)  As for altsettings...
usb_set_interface() sort of assumes they are stored in order.  (Actually,
it assumes the "alternate" parameter is an index for an altsetting,
whereas callers assume it is a bAlternateSetting value -- if the entries 
are in order that's not a problem.)

So either we should add accessor functions for configurations and
altsettings, or we remove the accessor for interfaces and verify that the
data structures are correct at the time they are created.  I lean toward
the latter, although it might end up being too hard to deal with really 
messed-up descriptors.

Alan Stern



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to