It works!!!!! Thanks Dave :) I hope this (or something like this) makes it to the next kernel release.
I'll submit it for 2.6.4-pre ... glad to know it behaves! I'd been a bit concerned about how the RNDIS+CDC devices would work, but they haven't seemed to be very prevalent. Yours was the first trouble report.
Just a few comments. -- In this patch, you have assumed that the communication interface is interface[0]. I am not sure that this is mandated by the spec. It works in my case. But it is better to check with the CDC spec.
Actually, what it's doing is coping with what MSFT seems to require. CDC doesn't say much about proprietary configs/interfaces.
As I understand, Windows doesn't handle config changes very well, and so it "mandates" that the MSFT-specific configurations be first. The main purpose for this heuristic is to avoid those dodgey MSFT policies ... there's no point (for now) in being more general.
-- As pointed out by you, this patch looks UGLY !! Treating special cases inside the usb core does not make good viewing.
Blame it on MSFT. It's their insistence that products avoid using vendor-neutral protocols, especially as the "default configuration" (first one listed), that causes all the problems.
-- Coming back to my previous mail, what is your opinion about this
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."
I feel this is a more generic and a better solution for all devices with
Except that as I pointed out, it can't possibly work since you can't probe an interface until its configuration is active. The drivers need to be able to issue requests to that interface during probe().
When you say "best fit", that's certainly a heuristic. Easily shown: in the MSFT calculus, "best" == "most MSFT-biased". In the open systems world, it's usually "most vendor neutral".
multiple configurations. Otherwise you would have to patch the heuristic for all the vendor specific variations in the market.
From the first Linux-USB release (2.2.8) up to 2.6.3, the ONLY two cases that have been common enough to be supported in mainstream kernels have been those two MSFT-oriented ones:
- Serial modems: first config is a WinModem, second is CDC ACM; - Ethernet links: first config is RNDIS, second is CDC Ethernet.
So the evidence is that (with this patch) we already cover all the important cases. Another technical solution has been discussed, but it'd involve adding new driver entry points -- which is worth avoiding as long as the only justification is making MSFT happy.
- Dave
Thanks again for the patch!! --Prashanth
----- Original Message ----- From: "David Brownell" <[EMAIL PROTECTED]>
To: "Prashanth Acharya" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, February 15, 2004 11:41 PM
Subject: Re: [linux-usb-devel] Modem with MSFT RNDIS & CDC-Ethernet working
with 2.4.x and not working with 2.6.2
Prashanth Acharya wrote:
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.
Well, see if the attached patch resolves the issue for you. It just teaches the existing heuristic to avoid RNDIS too, given the choice. Does it work for you?
- Dave
---------------------------------------------------------------------------- ----
Modifies "choose configuration" heuristic to recognize the other case that 2.4 handled: RNDIS, a MSFT protocol sometimes used as the first configuration on cable modems. CDC Ethernet is open, and preferred.
--- 1.156/drivers/usb/core/usb.c Mon Feb 9 19:55:34 2004 +++ edited/drivers/usb/core/usb.c Sun Feb 15 10:08:29 2004 @@ -1061,12 +1061,19 @@ config = dev->config[0].desc.bConfigurationValue; if (dev->descriptor.bNumConfigurations != 1) { for (i = 0; i < dev->descriptor.bNumConfigurations; i++) { + struct usb_interface_descriptor *desc; + /* heuristic: Linux is more likely to have class * drivers, so avoid vendor-specific interfaces. */ - if (dev->config[i].interface[0]->altsetting - ->desc.bInterfaceClass - == USB_CLASS_VENDOR_SPEC) + desc = &dev->config[i].interface[0] + ->altsetting->desc; + if (desc->bInterfaceClass == USB_CLASS_VENDOR_SPEC) + continue; + /* COMM/2/all is CDC ACM, except 0xff is MSFT RNDIS */ + if (desc->bInterfaceClass == USB_CLASS_COMM + && desc->bInterfaceSubClass == 2 + && desc->bInterfaceProtocol == 0xff) continue; config = dev->config[i].desc.bConfigurationValue; break;
------------------------------------------------------- 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
