Author Message

<  Everything Coding  ~  usb-modeswitch-data 20160612 breaks module loading

PostPosted: Sun Jul 24, 2016 11:21 am Reply with quote
Posts: 23 Joined: Wed Jun 22, 2016 2:17 pm
Hi.

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

The ChangeLog says this:

Code:
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:
# 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


Offline
PostPosted: Sun Jul 24, 2016 4:10 pm Reply with quote
Posts: 23 Joined: Wed Jun 22, 2016 2:17 pm
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


Offline
PostPosted: Mon Jul 25, 2016 5:02 am Reply with quote
Posts: 1166 Joined: Wed Jul 11, 2012 3:14 pm Location: Koh Samui, TH
lkundrak wrote:
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..


lkundrak wrote:
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! 8)


lkundrak wrote:
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.


lkundrak wrote:
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.


Offline
PostPosted: Mon Jul 25, 2016 9:06 am Reply with quote
Site Admin Posts: 6420 Joined: Sat Nov 03, 2007 12:30 am
I'll issue a bugfix release of the data package, with some proper clean-up.


Offline
PostPosted: Mon Jul 25, 2016 9:14 am Reply with quote
Site Admin Posts: 6420 Joined: Sat Nov 03, 2007 12:30 am
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.


Offline
PostPosted: Mon Jul 25, 2016 9:33 am Reply with quote
Posts: 1166 Joined: Wed Jul 11, 2012 3:14 pm Location: Koh Samui, TH
Josh wrote:
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?


Offline
PostPosted: Mon Jul 25, 2016 11:38 am Reply with quote
Site Admin Posts: 6420 Joined: Sat Nov 03, 2007 12:30 am
LOM wrote:
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!


Offline

Display posts from previous:  Sort by:

All times are UTC+02:00
Page 1 of 1
7 posts
Users browsing this forum: No registered users and 1 guest
Search for:
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum