USB: expose Huawei E1550 3G modem
Subsystems (2)
PATCH 1/1 USB: expose Huawei E1550 3G modem
From: Stefan Assmann <[email protected]>
The Huawei E1550 3G modem is hidden by default and can be exposed by sending some magic initialization code. This patch takes care of that.
--- drivers/usb/storage/initializers.c | 21 +++++++++++++++++++++ drivers/usb/storage/initializers.h | 3 +++ drivers/usb/storage/unusual_devs.h | 5 +++++ 3 files changed, 29 insertions(+), 0 deletions(-)
drivers/usb/storage/initializers.c +21 -0
@@ -102,5 +102,26 @@ int usb_stor_huawei_e220_init(struct us_data *us)USB_TYPE_STANDARD |USB_RECIP_DEVICE , 0x01, 0x0, NULL, 0x0, 1000);US_DEBUGP ("Huawei mode set result is %d\n" , result); + +return 0 ; +} + +/* This exposes the HUAWEI E1550 3G modem */ +int usb_stor_huawei_e1550_init (struct us_data *us) +{ +int result; +static char init_string[] = +"\x55\x53\x42\x43\x00\x00\x00\x00" +"\x00\x00\x00\x00\x00\x00\x00\x11" +"\x06\x00\x00\x00\x00\x00\x00\x00" +"\x00\x00\x00\x00\x00\x00\x00" ; + +memcpy (us->iobuf, init_string,sizeof (init_string) -1 ); + result =usb_stor_bulk_transfer_buf (us, us->send_bulk_pipe, + us->iobuf, +US_BULK_CB_WRAP_LEN , +NULL ); +US_DEBUGP ("Huawei mode set result is %d\n" , result); +return 0 ; }
drivers/usb/storage/initializers.h +3 -0
@@ -48,3 +48,6 @@ int usb_stor_ucr61s2b_init(struct us_data *us);/* This places the HUAWEI E220 devices in multi-port mode */ int usb_stor_huawei_e220_init (struct us_data *us); + +/* This exposes the HUAWEI E1550 3G modem */ +int usb_stor_huawei_e1550_init (struct us_data *us);
drivers/usb/storage/unusual_devs.h +5 -0
@@ -1814,6 +1814,11 @@ UNUSUAL_DEV( 0x12d1, 0x143F, 0x0000, 0x0000, "Mass Storage", US_SC_DEVICE, US_PR_DEVICE, usb_stor_huawei_e220_init, 0), +UNUSUAL_DEV (0x12d1 ,0x1446 ,0x0000 ,0x0000 , +"HUAWEI MOBILE" , +"Mass Storage" , +US_SC_DEVICE ,US_PR_DEVICE , usb_stor_huawei_e1550_init, +0 ),/* Reported by Vilius Bilinkevicius <vilisas AT xxx DOT lt) */ UNUSUAL_DEV( 0x132b, 0x000b, 0x0001, 0x0001,
Signature · 1 line
1.7.0.1
Quoted 3 lines · Stefan Assmann
The Huawei E1550 3G modem is hidden by default and can be exposed by sending some magic initialization code. This patch takes care of that.
This device (as all other Huaweis using this sequence) is supported by the usb_modeswitch tool which takes of the switching process. Once installed, no user interaction is required except plugging.
Current policy is to leave switching to the userspace if it's working there.
Josua Dietze
Quoted 5 lines · Josua Dietze
Quoted 3 lines · Stefan Assmann
The Huawei E1550 3G modem is hidden by default and can be exposed by sending some magic initialization code. This patch takes care of that.
Quoted 7 lines
This device (as all other Huaweis using this sequence) is supported by the
usb_modeswitchtool which takes of the switching process. Once installed, no user interaction is required except plugging.Current policy is to leave switching to the userspace if it's working there.
Hi Josua,
that's good news. This is part of hardware initialization, so let's move it to the kernel. Or do you know any good reason why the kernel shouldn't handle it?
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles CacheraQuoted 11 lines · Stefan Assmann
Quoted 10 lines · Josua Dietze
Quoted 3 lines · Stefan Assmann
The Huawei E1550 3G modem is hidden by default and can be exposed by sending some magic initialization code. This patch takes care of that.
This device (as all other Huaweis using this sequence) is supported by the
usb_modeswitchtool which takes of the switching process. Once installed, no user interaction is required except plugging.
Quoted 6 lines
Quoted 2 lines
Current policy is to leave switching to the userspace if it's working there.
that's good news. This is part of hardware initialization, so let's move it to the kernel. Or do you know any good reason why the kernel shouldn't handle it?
We've had this discussion, what, over a dozen times already? It keeps coming up every few months.
There are two primary reasons to keep this in userspace:
1) Someone might actually want to access the storage mode of these devices. It has come up in the past, and there is no good reason the kernel should deny access to that function of the device by enforcing a switchover.
2) It is much much easier to update a userspace tool than the kernel. Thus, new devices can be supported without a kernel update by end-users.
Matt
Signature · 7 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998
Quoted 19 lines · Matthew Dharm
Quoted 11 lines · Stefan Assmann
Quoted 10 lines · Josua Dietze
Quoted 3 lines · Stefan Assmann
The Huawei E1550 3G modem is hidden by default and can be exposed by sending some magic initialization code. This patch takes care of that.
This device (as all other Huaweis using this sequence) is supported by the
usb_modeswitchtool which takes of the switching process. Once installed, no user interaction is required except plugging.Quoted 6 lines
Quoted 2 lines
Current policy is to leave switching to the userspace if it's working there.
that's good news. This is part of hardware initialization, so let's move it to the kernel. Or do you know any good reason why the kernel shouldn't handle it?
Quoted 8 lines
We've had this discussion, what, over a dozen times already? It keeps coming up every few months.
There are two primary reasons to keep this in userspace:
1) Someone might actually want to access the storage mode of these devices. It has come up in the past, and there is no good reason the kernel should deny access to that function of the device by enforcing a switchover.
You're right about that. For the E1550 it doesn't hide any devices. I'm still able to access the virtual CDROM and the microSD card. Josua, you might know more about that, isn't the hidding of the CDROM/microSD part done separately?
Quoted 3 lines
2) It is much much easier to update a userspace tool than the kernel. Thus, new devices can be supported without a kernel update by end-users.
Of course. Nobody is talking about removing existing code from any user-space application. Under the condition that no functionality gets lost, wouldn't it be convenient to have the modem exposed by the kernel? If the kernel support doesn't suffice you can still run an updated usb_modeswitch until kernel support is there.
This also has the benefit that it would work for people that don't have usb_modeswitch installed. Matt, are you still thinking that is the wrong way of doing it?
Stefan
--
Stefan Assmann | Red Hat GmbH
Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach
| HR: Amtsgericht Muenchen HRB 153243
| GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com | Michael Cunningham, Charles CacheraQuoted 4 lines · Stefan Assmann
You're right about that. For the E1550 it doesn't hide any devices. I'm still able to access the virtual CDROM and the microSD card. Josua, you might know more about that, isn't the hidding of the CDROM/microSD part done separately?
This behaviour depends on the respective device. Most devices don't re-expose the installation medium after switching, some do.
Anyway, usb_modeswitch is on the road to becoming a standard part of the big distributions, so users won't have to look for it actively.
Josua Dietze
Quoted 11 lines · Stefan Assmann
Quoted 3 lines · Matthew Dharm
2) It is much much easier to update a userspace tool than the kernel. Thus, new devices can be supported without a kernel update by end-users.
Of course. Nobody is talking about removing existing code from any user-space application. Under the condition that no functionality gets lost, wouldn't it be convenient to have the modem exposed by the kernel? If the kernel support doesn't suffice you can still run an updated
usb_modeswitchuntil kernel support is there.
Quoted 3 lines
This also has the benefit that it would work for people that don't have
usb_modeswitchinstalled. Matt, are you still thinking that is the wrong way of doing it?
I still believe that, for an end-user, upgrading a userspace tool is much much easier than upgrading a kernel.
Also, the actual "driver" for the device (i.e. the modem part) doesn't need an upgrade to the kernel component for these types of devices.
Finally, these sorts of databases don't belong in the kernel as much as possible.
The usb-storage driver will not accept patches for device which can be supported via userspace-only tools.
Matt
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998
Quoted 19 lines · Matthew Dharm
Quoted 11 lines · Stefan Assmann
Quoted 3 lines · Matthew Dharm
2) It is much much easier to update a userspace tool than the kernel. Thus, new devices can be supported without a kernel update by end-users.
Of course. Nobody is talking about removing existing code from any user-space application. Under the condition that no functionality gets lost, wouldn't it be convenient to have the modem exposed by the kernel? If the kernel support doesn't suffice you can still run an updated
usb_modeswitchuntil kernel support is there.Quoted 3 lines
This also has the benefit that it would work for people that don't have
usb_modeswitchinstalled. Matt, are you still thinking that is the wrong way of doing it?I still believe that, for an end-user, upgrading a userspace tool is much much easier than upgrading a kernel.
Quoted 8 lines
Also, the actual "driver" for the device (i.e. the modem part) doesn't need an upgrade to the kernel component for these types of devices.
Finally, these sorts of databases don't belong in the kernel as much as possible.
The usb-storage driver will not accept patches for device which can be supported via userspace-only tools.
And just to confirm, I support Matthew's position.
thanks,
greg k-h