David Brownell wrote:

On Wednesday 13 October 2004 5:10 am, Brian Murphy wrote:


I have found out the problem is that the usb_parse_configuration
routine does not take account of descriptors which lie after the last
interface descriptor so the extralen parameters are set to 0 even though there *is* extra information.



Which in that case would be tacked on to the endpoint descriptor in that last interface, as "extra" descriptor data. It's not clear to me what you mean by "not take account of"...




OK but in 2.6.8.1 the endpoint extra info is not searched for class specific descriptors.
It seems perfectly reasonable to me to put these descriptors after the endpoint
descriptors.


The ACM probe routine however looks for the extra descriptors in the interface structure not in the configuration structure (where I think
they should be).



CDC descriptors should normally go right after the control
interface descriptor and before any status endpoint in that
interface. As it says in the CDC spec, section 5.2 where it
defines all the class-specific descriptors: "A class-specific
descriptor exists only at the Interface level." And it then
elaborates that the data interfaces don't have any.




You find a clarity of expression in the usb standards I do not but I have to
agree with you that this is the *right thing to do*.


There is however device firmware that puts CDC descriptors
in strange places.  As Oliver noted, the CDC drivers have
been adding workarounds so it can work better with such
devices.  (Also ones with bogus union descriptors...)




It seems that there is another dangerous bug in which any descriptors not parsed by usb_parse_configuration are assumed to be sequential



Huh? There are "extra" fields associated with configurations, interfaces, and endpoints. If you have firmware which for some reason doesn't put the CDC descriptors in the right place (after the control interface), there aren't many other places to search for them. I see no "danger"...




OK. But I have a Lasat modem which is ~6 years old which puts all the class specific
descriptors at the end after the *normal* descriptors and which has worked up to 2.6.7.


Now that we are chatting ;-), I don't see that the CDC standard specifies the necessity of
a union descriptor, a CDC modem should be perfectly capable of functioning without the
interrupt notification interface (just a control interface), I have certainly made one which
has a dummy interrupt interface to ensure compatibility with the linux driver but
which *never* sends anything over it as none of the information I can signal with it
(according to the specification) is useful. Is it then a good thing to rely on the existance
of a union descriptor to signal the validity of a CDC device?


/Brian


------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to