[kultex]

I am trying to add automatic switching of umts modems for slitaz http://www.slitaz.org - my huawei E220 did not switch. I realized on my try, that the Huawei E220 does not need usb_modeswitch any more - at least from kernel 2.6.30 - I just had to laod the option driver and it switched perfectly.
My first question: thus slitaz is tricky in debugging udev. Can it be, that the kernel is handling the E220, so it does not match the udev-80-usb_modeswitch.rules? Because otherwhise it should have still load the option driver with usb_modeswitch.tcl.
second question: do you perhaps know about other modems, who do not need usb_modeswitch any more?

[kultex]

addition to the first question: I think it must be like this, because in fluxflux-sl - http://lin2go.com/ - , which was all the time using usb_modeswitch first with ivman and now with usb_modeswitch.tcl, the Huawei E220 is switching after removing the udev 80.rules - and there I even do not have to load option

output from dmesg:

Code: Select all

usb 3-1: new full speed USB device using uhci_hcd and address 2
usb 3-1: New USB device found, idVendor=12d1, idProduct=1003
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: HUAWEI Mobile
usb 3-1: Manufacturer: HUAWEI Technologies
usb 3-1: configuration #1 chosen from 1 choice
usb-storage: probe of 3-1:1.0 failed with error -1
usb 3-1: USB disconnect, address 2
usb 3-1: new full speed USB device using uhci_hcd and address 3
usb 3-1: New USB device found, idVendor=12d1, idProduct=1003
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: HUAWEI Mobile
usb 3-1: Manufacturer: HUAWEI Technologies
usb 3-1: configuration #1 chosen from 1 choice
usb-storage: probe of 3-1:1.2 failed with error -1
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
option 3-1:1.0: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB0
option 3-1:1.1: GSM modem (1-port) converter detected
usb 3-1: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
gast@ff-sl: ~ $ 

[Josh]

Good question.

The state of switching in the kernel is this:

• "Older" Huawei devices are switched by "usb-storage"; newer devices are not. You can see which ones in "<kernel source>/drivers/usb/storage/unusal_devs.h". Look for "e220_init" ...
• Other devices switched in usb-storage are some Option modems and the Sierra range of devices
• The USB developer don't like the switching by the kernel very much. As soon as USB_ModeSwitch is available for all major distributions, most remaining device switching code will be removed from the kernel
• Staying in the kernel will probably the Sierra code; they have actually implemented Linux support on the "driver part" of some of their modems. So they decide about switching after inquiring the respective device and checking for Linux software first.

I have tried to implement the automatic switching so as not to interfere with previous kernel switching attempts.
If the device is gone before the hotplug rule is reached, no action is started at all.
If the switching action is completed and the switched device is known to a driver and bound immediately, the "option" module will not be loaded and bound by the tcl script.

The ID of the Huawei E220 should long be included in the "option" driver; usually the serial devices are discovered right after switching.

[kultex]

thx for your answer - and, I found, what is witching in fluxflux-sl - /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi - so all modems, which are in there, are switched by hal and if it is not in there, it will go to the udev-80.rules

[Josh]

Personally, I'd rather like to see just one defined place for the switching actions. The different approaches tend to interfere, sometimes badly.

I would not care if distributors chose my solution or someone else's. That said, the latest version of USB_ModeSwitch takes care of 97 different devices ...

The best approach would certainly be to concentrate all energy and knowledge on one single solution and to improve that gradually.

[kultex]

I think the same - its a pitty, all this "lost" energy

[EiraJeremie]

It's possible that the kernel is handling the E220, which could explain why it didn't match the udev-80-usb_modeswitch.rulesmy location.