[Josh]

Up to now I did the rule matching based on interfaces because of the rules to check the class of the first interface, refusing all but storage class devices.

Now I have changed the rule file to match only the 'top' devices; I moved the interface check to the wrapper.

The "add" event seems to be working for hot-plugging; I have yet to test the boot behaviour though.

Again, no multi-config device to test with.
Can you check if a configuration change via "echo" will trigger the usb_modeswitch rules?

Here are the files:
http://www.draisberghof.de/usb_modeswit ... a2.tar.bz2
http://www.draisberghof.de/usb_modeswit ... 1x.tar.bz2

(The changes in the data package are limited to the rules file and the 12d1:1446 config.)

[bmork]

Up to now I did the rule matching based on interfaces because of the rules to check the class of the first interface, refusing all but storage class devices.

Now I have changed the rule file to match only the 'top' devices; I moved the interface check to the wrapper.

The "add" event seems to be working for hot-plugging; I have yet to test the boot behaviour though.

Again, no multi-config device to test with.
Can you check if a configuration change via "echo" will trigger the usb_modeswitch rules?

Here are the files:
http://www.draisberghof.de/usb_modeswit ... a2.tar.bz2
http://www.draisberghof.de/usb_modeswit ... 1x.tar.bz2

(The changes in the data package are limited to the rules file and the 12d1:1446 config.)

Nice. This works as expected, switching to configuration #2 if I set CheckMBIM, but still allowing me to manually switch the configuration back to 1.

I will use it for a while and let you know if there are any unexpected side effects.

One issue that has come up is that the MBIM support might be integrated into the existing cdc_ncm driver instead of getting its own driver. MBIM was previously known as NCM 2.0, and the differences seen by the driver are minor. The MBIM spec also defines a NCM compat mode where the control interface will have both NCM and MBIM altsettings. This may make it more difficult to detect kernel MBIM support. But anything is possible. You could maybe base the detection on the MBIM subclass modalias?

Code: Select all

bjorn@nemi:/tmp$ modinfo  /usr/local/src/git/linux/drivers/net/usb/cdc_ncm.ko|grep ic02isc0E
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Eip00in*

Bjørn

[Josh]

One issue that has come up is that the MBIM support might be integrated into the existing cdc_ncm driver instead of getting its own driver. MBIM was previously known as NCM 2.0, and the differences seen by the driver are minor. The MBIM spec also defines a NCM compat mode where the control interface will have both NCM and MBIM altsettings. This may make it more difficult to detect kernel MBIM support. But anything is possible. You could maybe base the detection on the MBIM subclass modalias?

I'm sure that won't be hard to handle. The most straightforward way for me would be a unique sysfs attribute (after loading the driver), but I could check the module directly as you say - or i could have a look at the "modules.usbmap" file.

A short question about a different issue: do you know of any qmi_wwan backport yet?

I just got myself a E398 and am playing around with it. The "linux-next" compilation is running right now, but I'm not sure if I can use that kernel on my home-grown router.

[bmork]

One issue that has come up is that the MBIM support might be integrated into the existing cdc_ncm driver instead of getting its own driver. MBIM was previously known as NCM 2.0, and the differences seen by the driver are minor. The MBIM spec also defines a NCM compat mode where the control interface will have both NCM and MBIM altsettings. This may make it more difficult to detect kernel MBIM support. But anything is possible. You could maybe base the detection on the MBIM subclass modalias?

I'm sure that won't be hard to handle. The most straightforward way for me would be a unique sysfs attribute (after loading the driver), but I could check the module directly as you say - or i could have a look at the "modules.usbmap" file.

Good. Then we don't have to worry about that.

A short question about a different issue: do you know of any qmi_wwan backport yet?

I did backport an earlier version to 3.2:
http://bugs.debian.org/670241

but that is incomplete now, given the number of critical fixes since then.

It should be fairly easy to "backport" the newest releases by just copying qmi_wwan.c, cdc_wdm.c and cdc_wdm.h and fixing a few minor issues. The biggest problem will be the missing interface number matching, but if you can build the whole kernel (or at least the usb-core) then that should be fixable by cherry-picking

Code: Select all

 commit 81df2d59 USB: allow match on bInterfaceNumber

I just got myself a E398 and am playing around with it. The "linux-next" compilation is running right now, but I'm not sure if I can use that kernel on my home-grown router.

3.6 should be in pretty good shape when it's out.

[Josh]

Worked like a charm.

My router did not balk on kernel 3.5.3, and I used the three files from "next" together with that single patch - hardly a veritable backport, but now I have the latest version ...

Many thanks for all your work on this !

I have followed the 'genesis' of the qmi driver with great interest (on 'linux-usb').

[bmork]

Just an update on the MBIM driver status now that it seems to stabilize. The initial version was just accepted into net-next, which means that it should show up in Linux v3.8. After a bit back and forth, the end result was that a new cdc_mbim driver was created as a separate module. So detecting the driver presence will be a simple matter of looking for cdc_mbim.ko:

Code: Select all

bjorn@nemi:/var/tmp$ modinfo /lib/modules/3.7.0-rc1+/kernel/drivers/net/usb/cdc_mbim.ko 
filename:       /lib/modules/3.7.0-rc1+/kernel/drivers/net/usb/cdc_mbim.ko
license:        GPL
description:    USB CDC MBIM host driver
author:         Bjørn Mork <bjorn@mork.no>
author:         Greg Suarez <gsuarez@smithmicro.com>
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Eip00in*
alias:          usb:v*p*d*dc*dsc*dp*ic02isc0Dip00in*
depends:        usbnet,usbcore,cdc-wdm,cdc_ncm
intree:         Y
vermagic:       3.7.0-rc1+ SMP mod_unload modversions 

(Note that the NCM alias is included to catch MBIM devices implementing a NCM compatibility mode - probing will decide whether the device is MBIM or NCM)

I have been using the usb_modeswitch patch you posted previously for all my testing so far, and it works perfectly with the single MBIM device I've got. The driver path should of course be updated. But as far as I can see, the solution is ready for release. Including it in a release before Linux v3.8 (guesstimate: February 2013) is probably a good idea if that fits into your release plans.


Bjørn

[Josh]

Thanks for the update.

One more question though: is there a path or a specific system attribute in the sysfs tree that can be checked in case the driver is already loaded or compiled into the kernel?

[bmork]

Thanks for the update.

One more question though: is there a path or a specific system attribute in the sysfs tree that can be checked in case the driver is already loaded or compiled into the kernel?

Good question. The best place to check is probably
/sys/bus/usb/drivers/cdc_mbim


Bjørn

[Josh]

That will do.

I'm beginning to prepare the next release which will incorporate the changes.

[Josh]

I've sent you a link to a 'preview' of the new release. Maybe you'll find some time to test it ...