Thanks for responding Dave!!!! > > 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! >
Agreed! As requested in previous mail, pardon my ignorance... ;) > 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). > Does this mean only the hub driver has the ability of chosing the configuration? This sounds a bit quirky to me!! > > > 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.) Agreed that CDC Ethernet is simpler!!! :) Does this mean that the CDC ACM driver is probed with my config 1? If yes, will it help if I disable CDC-ACM support in my kernel? > > 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. > The existing heuristic clearly does not work if there are two non-vendor specific interfaces. I agree that it will be ugly if we include something only for the RNDIS case. It must be noted that though the interface is non-vendor specific, the protocol reported by RNDIS is vendor specific. Maybe the heuristic should consider this also. Also can I expect this update to the heuristic in the near future?? > > > 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. > > I am not very sure abt how "hotplug" works... just assumed that it will have the ability to do a "set configuration"..... which is not the case, as pointed out by you. It appears to me that in 2.6, the set_config happens before probing of drivers. IMHO, the sequence should be reversed !! i.e. probe the configs sequentially till at least one of the interfaces is "claimed" and then do a "set config" for that configuration. This line of thought arises out of the fact that only hub driver can do a set_configuration. So the hub driver should do something like a best-effort or a best fit in chosing a configuration. > > 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). > OOPS!! I am working on a system that will go into mass production. So my modem should be able to work "out of the box" with all MSFT windows, Linux2.4, Linux 2.6 etc etc. So this solution is not quite feasible :( . It would be really ugly to say that this modem will work with MSFT, Linux2.4 "out of the box" and it will not do so with 2.6. and that one has to do XYZ to get the modem to work. >From my point of view, it would be ideal if the change occurs in the 2.6 kernel ;-) > 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. Agreed. I overlooked this line of thought. -- Prashanth. ------------------------------------------------------- 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
