Prashanth Acharya wrote:
After going thru some of the mails in this list and studying the USB source
tree for 2.6.2, my analysis is as follows:
My modem offers 2 configurations (bNumConfigurations=2) Config 1 = MSFT
RNDIS & config 2 = CDC Ethernet. In 2.4, the usb core would end up probing
config 2 with the CDCEther driver and successfully attach that driver. Now
in 2.6 the usbnet driver is not probed at all !!!!
Go back and read that 2.4 code again ... :)
What was actually happening on 2.4 was that CDCEther_probe() was getting called in the first config ... but it then switched to the second config!
That model just doesn't work on 2.6 kernels. (And it didn't work very well on 2.4 kernels either, except for certain types of device.) There are no drivers that call usb_set_configuration() any more, except the hub driver (which is part of usbcore).
1. the config chosen in my case is config 1... b'cos my RNDIS descriptor does NOT say it is a vendor specific interface ( a quick fix soln of modem reporting this vendor specific interface worked ok with Lnux 2.6.2 but destroyed the functionality with MSFT windows!!!!!!!) ...
That "vendor specific interface" heuristic helps Linux skip over winmodem configurations, where config 1 is "WinModem" and config 2 is "CDC ACM".
It doesn't help in the case of RNDIS, since in its (non-)wisdom Microsoft created an Ethernet interface that's a vendor-specific variant of CDC ACM. (Instead of using CDC Ethernet, which is a lot simpler than RNDIS.)
Of course, it would be possible to teach 2.6 specifically about RNDIS, growing that heuristic by recognizing RNDIS as another proprietary interface ... logically a one-liner, albeit ugly.
2. usb_hotplug also does not run thru all configurations... it only runs thru interfaces... that too only if bDeviceClass==0
Well, the bDeviceClass limitation should really vanish, now that all the interfaces are getting hotplugged.
But probing all configurations would be nonsensical; at a given time, there's only one configuration to probe.
IMHO, if in a configuration, none of the interfaces are claimed by drivers and more configurations are available then those configs should be tried..
You can implement that policy today in userspace, with a custom hotplug (or maybe udev) setup that forces the modem into your preferred-on-Linux configuration (using sysfs bConfigurationValue).
The kernel can't implement that policy robustly in the typical case (with modular USB device drivers) since the "claim" can happen arbitrarily long after the device connects.
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
