[lkundrak]

Hi.

For some modems the device IDs are still missing in the Linux source.

The ChangeLog says this:

Code: Select all

20160612:
...
    "NoDriverLoading" parameter removed from all configs, with respect
    to removed feature in usb-modeswitch 2.4.0

However the quick look at usb-modeswitch 2.4.0 reveals the option is still there and it was even nor removed from the usb-modeswitch-data 20160612 files.

However, what was removed was the UDev rule to do the binding:

Code: Select all

# Adds the device ID to the "option" driver after a warm boot
# in cases when the device is yet unknown to the driver; checked
# against a list of known modems, or else no action
ATTR{bInterfaceClass}=="ff", ATTR{bInterfaceNumber}=="00", ATTRS{bNumConfigurations}=="*", RUN+="usb_modeswitch --driver-bind %p %s{idVendor} %s{idProduct} %E{PRODUCT}"

It was not removed from the gen-rules.tcl though. Therefore the generated rules file no longer corresponds tu what is shipped in the tarball.

What was the desired intent here? How should the distribution maintainers handle this? Is the driver binding feature/hack being removed?

Thanks
Lubo

[lkundrak]

Ok, I get it now. I didn't read the ChangeLog before; sorry for that.

Nevertheless, the usb-modeswitch-data is still a bit chaotic: NoDriverLoading has not been removed contrary to what ChangeLog claims and the generated rule file still tries to bind the drivers. That perhaps still needs fixing.

Also, there probably still are devices without proper aliases in Linux kernel drivers. At least one of my devices was not recognized (patch sent) and by the quick look at the device list I suspect there are more (e.g. 0408:ea16 and 0408:ea26 -- can't test them as I don't have the hardware). Those are going to fail silently now.

I'm wondering if a warning message could be produced if there are interfaces with no driver bound after the mode switch, so that users could report those and the driver could be fixed?

Lubo

[LOM]

Nevertheless, the usb-modeswitch-data is still a bit chaotic: NoDriverLoading has not been removed contrary to what ChangeLog claims and the generated rule file still tries to bind the drivers. That perhaps still needs fixing.

It is only a matter of cleaning up old code, probably forgotten by Josh during a late night package production session..

Also, there probably still are devices without proper aliases in Linux kernel drivers. At least one of my devices was not recognized (patch sent)

So you recognized this because usb_modeswitch does no longer mask the lack of real driver support. Good!

and by the quick look at the device list I suspect there are more (e.g. 0408:ea16 and 0408:ea26 -- can't test them as I don't have the hardware). Those are going to fail silently now.

Yes, so users who want to have them supported must do something to get them supported, usb_modeswitch is a mode switching tool and not a driver loading tool.

I'm wondering if a warning message could be produced if there are interfaces with no driver bound after the mode switch, so that users could report those and the driver could be fixed?

There is often interfaces which should be excluded from serial driver binding so it is not possible to check that all interfaces has a driver attached, you can not automate this unless you have a database of interface numbers by usb id.
There was a warning message in the past when usb_modeswitch had loaded the option driver and used the new_id function for binding the driver. The result was not more devices being reported to linux maintainers for driver support, most users didn't care to do that because of the "it is working for me, why care" syndrome.
The few reported cases were mostly false positives due to detection timing errors.

[Josh]

I'll issue a bugfix release of the data package, with some proper clean-up.

[Josh]

Regarding the module loading - there were cases reported by Dan Williams (Network Manager, modemmanager) where the module loading of usb_modeswitch interfered with the kernel module loading.

For serial modems that are not yet explicitely supported by the "option" driver, the manual remedy is relatively easy to apply: load the module, add the modem ID through the "new_id" interface.

Should be no problem for the mostly professional users of those stable but dated 'enterprise' distributions.

Recent modems on the other hand tend to move away from serial ports anyway.

[LOM]

I'll issue a bugfix release of the data package, with some proper clean-up.

I have a long long list of devices to add and a few corrections of present ones, can we include those at the same time?

[Josh]

I have a long long list of devices to add and a few corrections of present ones, can we include those at the same time?

Sure!