Retire modem-modeswitch for non-option devices?

Retire modem-modeswitch for non-option devices?

[Felix Schwarz]

Hi,

I'm trying to add support for my UMTS USB stick (Huawei 3765) to udev. 
Until yesterday I was pretty sure that I need to patch modem-modeswitch 
+ adding some udev rules.

However today I found changeset 8a993fab2f218234f06743bcc127dda61a45711b 
by Dan Williams committed on Nov 23 which basically says that it is 
completely wrong to use 'option-zerocd' for non-option devices.

Dan send a reasoning before doing his revert:
http://www.spinics.net/lists/hotplug/msg03143.html

More specifically he wrote:
"All further modem eject stuff should really handled by usb_modeswitch,
not by modem-modeswitch.  I'll follow up with a patch for the rules file
saying that only Option devices should be added, and that usb_modeswitch
is really the right place for this stuff."

I'm puzzled by that...
1. Does that mean that you (udev upstream) declare modem-modeswitch a
    dead end and everybody should look at usb_modeswitch?
2. If a supposedly wrong string works on real hardware for real users -
    how can it be wrong? You might want to argue that a parameter
    'option-zerocd' is wrong for non-option devices and we should use a
    different name for the parameter...
3. If usb_modeswitch is the way to go, are you comfortable adding this
     as a dependency (by including rules which call usb_modeswitch)?

fs

PS: cc'ing Dan as he's not on the list afaik, cc'ing Martin because he 
commited the original commit and is in charge for the original Ubuntu bug.

Re: Retire modem-modeswitch for non-option devices?

[Dan Williams]

On Tue, 2010-01-05 at 22:58 +0100, Felix Schwarz wrote:
> Hi,
> 
> I'm trying to add support for my UMTS USB stick (Huawei 3765) to udev. 
> Until yesterday I was pretty sure that I need to patch modem-modeswitch 
> + adding some udev rules.
> 
> However today I found changeset 8a993fab2f218234f06743bcc127dda61a45711b 
> by Dan Williams committed on Nov 23 which basically says that it is 
> completely wrong to use 'option-zerocd' for non-option devices.
> 
> Dan send a reasoning before doing his revert:
> http://www.spinics.net/lists/hotplug/msg03143.html
> 
> More specifically he wrote:
> "All further modem eject stuff should really handled by usb_modeswitch,
> not by modem-modeswitch.  I'll follow up with a patch for the rules file
> saying that only Option devices should be added, and that usb_modeswitch
> is really the right place for this stuff."
> 
> I'm puzzled by that...
> 1. Does that mean that you (udev upstream) declare modem-modeswitch a
>     dead end and everybody should look at usb_modeswitch?

Yes.

> 2. If a supposedly wrong string works on real hardware for real users -
>     how can it be wrong? You might want to argue that a parameter
>     'option-zerocd' is wrong for non-option devices and we should use a
>     different name for the parameter...

Using the 'rezero' code for ZTE devices caused real problems even though
for some users it appeared to work.  ZTE engineers also independently
asked me to revert it.

Every manufacturer uses a different eject method.  You should only use
the *correct* eject method for a specific device.  Using the Option
NV-specific 'rezero' method is simply incorrect for ZTE devices, which
usually need only a simple eject.  Likewise, using the 'rezero' method
is incorrect for Huawei devices, because they use a different eject
method.

Using an incorrect eject method can confuse the device's firmware and
cause it to incorrectly reenumerate, or incorrectly reply to the kernel
after it has ejected the fake CD.

Dan

> 3. If usb_modeswitch is the way to go, are you comfortable adding this
>      as a dependency (by including rules which call usb_modeswitch)?