Hello Franko,
This patch causes a number of regressions for both the Huawei devices I
have available for testing. One of them is completely unusable in v3.8
(unable to switch to modem mode) unless the usb-storage driver is
disabled.
I realize that some devices are historically handled by the usb-storage
driver, but userspace modeswitching is the rule for new devices AFAIK.
I see absolutely no valid argument for adding new devices. And there is
absolutely no excuse for adding devices which have been handled by
userspace switching for years! The patch does not just "optimize"
matching. It adds a large number of devices which were previously
handled just fine by usb_modeswitch. This is guaranteed to confuse users
with existing configurations, and users looking up any of the existing
documentation pointing to usb_modeswitch.
There is no need to repeat the discussion of kernel vs userspace
switching. I will only note that userspace switching:
- has been selected as the rule for new devices,
- allow the user to temporarily disable switching e.g. for mounting and
inspecting the usb-storage exported data,
- allow the user/system to apply device specific switching quirks
The v3.7->v3.8 regressions I observe are:
1) Temporarily disabling mode switching and mounting the CD image is now
impossible. Mode switching can only be disabled by blacklisting
usb-storage, which of course prevents usb-storage from working
Prior to v3.8, modeswitching could easily be disabled by userspace
configuration. The change breaks existing configurations.
2) Switching to non-default modes is now impossible. The E392
(initially appearing as 12d1:1505) Windows drivers will use a different
command than the one used by Linux, causing the device to select a
different configuration in Linux and Windows. This forces Linux and
Windows to see the device differently.
Prior to v3.8, different modeswitching commands could be configured
per device. The change breaks existing configurations.
3) Switching fails for some devices. The E367 (initially appearing as
12d1:1446) does not switch when it receives the command sent by
usb-storage. But the command disable further switching, preventing
userspace switching from working as well.
Prior to v3.8, the device would switch fine using a default
usb_modeswitch configuration. The change breaks existing
configurations.
I do note that there is a slight difference between the known working
usb_modeswitch command:
55534243123456780000000000000011062000000100000000000000000000
and the command sent by usb-storage:
char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
I assume the cause of the failure is either this difference or some
timing issue.
Anyway, I believe this patch must be reverted. It disables currently
used, well documented, and extremely useful, userspace funtionaliy for
all devices implicitly added by the conversion from device matching to
vendor matching.
Bjørn
This reverts commit 200e0d99 ("USB: storage: optimize to match the
Huawei USB storage devices and support new switch command" and the
followup bugfix commit cd060956 ("USB: storage: properly handle
the endian issues of idProduct").
The commit effectively added a large number of Huawei devices to
the deprecated usb-storage mode switching logic. Many of these
devices have been in use and supported by the userspace
usb_modeswitch utility for years. Forcing the switching inside
the kernel causes a number of regressions as a result of ignoring
existing onfigurations, and also completely takes away the ability
to configure mode switching per device/system/user.
Known regressions caused by this:
- Some of the devices support multiple modes, using different
switching commands. There are existing configurations taking
advantage of this.
- There is a real use case for disabling mode switching and
instead mounting the exposed storage device. This becomes
impossible with switching logic inside the usb-storage driver.
- At least on device fail as a result of the usb-storage switching
command, becoming completely unswitchable. This is possibly a
firmware bug, but still a regression because the device work as
expected using usb_modeswitch defaults.
In-kernel mode switching was deprecated years ago with the
development of the more user friendly userspace alternatives. The
existing list of devices in usb-storage was only kept to prevent
breaking already working systems. The long term plan is to remove
the list, not to add to it. Ref:
http://permalink.gmane.org/gmane.linux.usb.general/28543
Cc: <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Bjørn Mork <[email protected]>
---
I just realized that this already had gone into maintained stable
series', making the fix so much more urgent. This needs to be
reverted before it starts hitting innocent distro users. So I
am sending the patch now instead of waiting for Huawei to respond.
Bjørn
drivers/usb/storage/initializers.c | 76 +--------
drivers/usb/storage/initializers.h | 4 +-
drivers/usb/storage/unusual_devs.h | 329 +++++++++++++++++++++++++++++++++++-
3 files changed, 331 insertions(+), 78 deletions(-)
diff --git a/drivers/usb/storage/initializers.c b/drivers/usb/storage/initializers.c
index 7ab9046..105d900 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_data *us)
return 0;
}
-/* This places the HUAWEI usb dongles in multi-port mode */
-static int usb_stor_huawei_feature_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)
{
int result;
@@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(struct us_data *us)
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
}
-
-/*
- * It will send a scsi switch command called rewind' to huawei dongle.
- * When the dongle receives this command at the first time,
- * it will reboot immediately. After rebooted, it will ignore this command.
- * So it is unnecessary to read its response.
- */
-static int usb_stor_huawei_scsi_init(struct us_data *us)
-{
- int result = 0;
- int act_len = 0;
- struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
- char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
- bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
- bcbw->Tag = 0;
- bcbw->DataTransferLength = 0;
- bcbw->Flags = bcbw->Lun = 0;
- bcbw->Length = sizeof(rewind_cmd);
- memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
- memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
-
- result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
- US_BULK_CB_WRAP_LEN, &act_len);
- US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
- return result;
-}
-
-/*
- * It tries to find the supported Huawei USB dongles.
- * In Huawei, they assign the following product IDs
- * for all of their mobile broadband dongles,
- * including the new dongles in the future.
- * So if the product ID is not included in this list,
- * it means it is not Huawei's mobile broadband dongles.
- */
-static int usb_stor_huawei_dongles_pid(struct us_data *us)
-{
- struct usb_interface_descriptor *idesc;
- int idProduct;
-
- idesc = &us->pusb_intf->cur_altsetting->desc;
- idProduct = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
- /* The first port is CDROM,
- * means the dongle in the single port mode,
- * and a switch command is required to be sent. */
- if (idesc && idesc->bInterfaceNumber == 0) {
- if ((idProduct == 0x1001)
- || (idProduct == 0x1003)
- || (idProduct == 0x1004)
- || (idProduct >= 0x1401 && idProduct <= 0x1500)
- || (idProduct >= 0x1505 && idProduct <= 0x1600)
- || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
- return 1;
- }
- }
- return 0;
-}
-
-int usb_stor_huawei_init(struct us_data *us)
-{
- int result = 0;
-
- if (usb_stor_huawei_dongles_pid(us)) {
- if (le16_to_cpu(us->pusb_dev->descriptor.idProduct) >= 0x1446)
- result = usb_stor_huawei_scsi_init(us);
- else
- result = usb_stor_huawei_feature_init(us);
- }
- return result;
-}
diff --git a/drivers/usb/storage/initializers.h b/drivers/usb/storage/initializers.h
index 5376d4f..529327f 100644
--- a/drivers/usb/storage/initializers.h
+++ b/drivers/usb/storage/initializers.h
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data *us);
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI usb dongles in multi-port mode */
-int usb_stor_huawei_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);
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 72923b5..d305a5a 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1527,10 +1527,335 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x0100,
/* Reported by fangxiaozhi <[email protected]>
* This brings the HUAWEI data card devices into multi-port mode
*/
-UNUSUAL_VENDOR_INTF(0x12d1, 0x08, 0x06, 0x50,
+UNUSUAL_DEV( 0x12d1, 0x1001, 0x0000, 0x0000,
"HUAWEI MOBILE",
"Mass Storage",
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_init,
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1003, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1004, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1401, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1402, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1403, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1404, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1405, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1406, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1407, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1408, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1409, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140A, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140B, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140C, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140D, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140E, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x140F, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1410, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1411, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1412, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1413, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1414, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1415, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1416, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1417, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1418, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1419, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141A, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141B, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141C, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141D, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141E, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x141F, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1420, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1421, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1422, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1423, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1424, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1425, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1426, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1427, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1428, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1429, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142A, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142B, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142C, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142D, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142E, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x142F, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1430, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1431, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1432, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1433, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1434, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1435, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1436, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1437, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1438, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x1439, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143A, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143B, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143C, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143D, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143E, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
+ 0),
+UNUSUAL_DEV( 0x12d1, 0x143F, 0x0000, 0x0000,
+ "HUAWEI MOBILE",
+ "Mass Storage",
+ USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
0),
/* Reported by Vilius Bilinkevicius <vilisas AT xxx DOT lt) */
--
1.7.10.4
On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
[...]
> In-kernel mode switching was deprecated years ago with the
> development of the more user friendly userspace alternatives. The
> existing list of devices in usb-storage was only kept to prevent
> breaking already working systems. The long term plan is to remove
> the list, not to add to it. Ref:
> http://permalink.gmane.org/gmane.linux.usb.general/28543
[...]
Can you add a comment to this effect?
Ben.
--
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.
Ben Hutchings <[email protected]> writes:
> On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
> [...]
>> In-kernel mode switching was deprecated years ago with the
>> development of the more user friendly userspace alternatives. The
>> existing list of devices in usb-storage was only kept to prevent
>> breaking already working systems. The long term plan is to remove
>> the list, not to add to it. Ref:
>> http://permalink.gmane.org/gmane.linux.usb.general/28543
> [...]
>
> Can you add a comment to this effect?
In the table in unusual_devs.h, you mean? Sure, I can do that.
But it feels a bit strange since I can only quote and/or refer to what
Matthew and Greg said about the issue years ago. Putting a comment in
the code to remind the current maintainers about their own statements
could be considered out of line? Or is this appropriate here?
Bjørn
Frankly, I consider it appropriate.
The question is not one of reminding me of what I said earlier....
it's one of pointing people in the right direction. Frankly, some of
the fault for this patch lies with Greg and myself for letting it
through. I had just assumed that the Huawei guys had already been in
touch with usb-modeswitch for some reason, and that this was just an
optimization of existing logic (not an expansion). And, frankly, I
was just a bit tired of fighting this fight over and over again;
having something in the file which says "here's the right and official
way to do this" would be good.
I also asked the Huawei guys about the possibility of affecting other
devices than the one listed.... I guess one of us either wasn't clear
or mis-understood the request. The fact that there are devices out
there failing now illustrates that. Avoiding breaking existing
systems is one of the highest priorities....
Who is maintaining usb-modeswitch these days, anyway? The comment in
the file should point people directly there....
And, as of now, I would really like to see as many of these devices
migrated (albeit slowly) to using usb-modeswitch wherever possible. I
know there are a few devices for which that might not be possible, but
I am DONE dealing with this same issue over and over and over again.
It will certainly be work to migrate support; maybe we should wrap all
the relevant unusual_devs.h entires with
CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
transition period?
Matt
On Mon, Mar 4, 2013 at 8:47 AM, Bj?rn Mork <[email protected]> wrote:
> Ben Hutchings <[email protected]> writes:
>> On Mon, 2013-03-04 at 14:19 +0100, Bj?rn Mork wrote:
>> [...]
>>> In-kernel mode switching was deprecated years ago with the
>>> development of the more user friendly userspace alternatives. The
>>> existing list of devices in usb-storage was only kept to prevent
>>> breaking already working systems. The long term plan is to remove
>>> the list, not to add to it. Ref:
>>> http://permalink.gmane.org/gmane.linux.usb.general/28543
>> [...]
>>
>> Can you add a comment to this effect?
>
> In the table in unusual_devs.h, you mean? Sure, I can do that.
>
> But it feels a bit strange since I can only quote and/or refer to what
> Matthew and Greg said about the issue years ago. Putting a comment in
> the code to remind the current maintainers about their own statements
> could be considered out of line? Or is this appropriate here?
>
>
> Bj?rn
--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
Matthew Dharm <[email protected]> writes:
> Frankly, I consider it appropriate.
OK, I'll try to cook something up.
> The question is not one of reminding me of what I said earlier....
> it's one of pointing people in the right direction. Frankly, some of
> the fault for this patch lies with Greg and myself for letting it
> through. I had just assumed that the Huawei guys had already been in
> touch with usb-modeswitch for some reason, and that this was just an
> optimization of existing logic (not an expansion). And, frankly, I
> was just a bit tired of fighting this fight over and over again;
> having something in the file which says "here's the right and official
> way to do this" would be good.
>
> I also asked the Huawei guys about the possibility of affecting other
> devices than the one listed.... I guess one of us either wasn't clear
> or mis-understood the request. The fact that there are devices out
> there failing now illustrates that. Avoiding breaking existing
> systems is one of the highest priorities....
Well, I am a bit embarrassed by this. I did notice the patch and even
looked through it when it was posted. But when I later noticed the
switching failure I didn't think more about it at all. I just put the
error on my to-be-investigated-further list. Which tends to erase
itself before I get to it...
> Who is maintaining usb-modeswitch these days, anyway? The comment in
> the file should point people directly there....
That would be Josua Dietze, who I intended to CC from the beginning of
this discussion but forgot... Sorry about that. I'm certainly not
going to complain about anyone else forgetting stuff :)
CCed now. Josh, I assume it's OK for you if we put a pointer to
http://www.draisberghof.de/usb_modeswitch/ in the unusual_devs.h code?
> And, as of now, I would really like to see as many of these devices
> migrated (albeit slowly) to using usb-modeswitch wherever possible. I
> know there are a few devices for which that might not be possible, but
> I am DONE dealing with this same issue over and over and over again.
> It will certainly be work to migrate support; maybe we should wrap all
> the relevant unusual_devs.h entires with
> CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
> transition period?
Sounds good to me, if that is acceptable to the user interface stability
committee.
I guess the real problem will be verifying that all of the entries *can*
go away. This type of hardware tends to get old very fast, but there is
always someone having a really ancient device.
Maybe we could use the same method the netdev people use when they want
to remove stuff: Subtly break it and leave it like that for a few years
before finally deleting it, arguing that noone can be using the feature
because it's broken :)
Bjørn
> On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork <[email protected]> wrote:
>> Ben Hutchings <[email protected]> writes:
>>> On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
>>> [...]
>>>> In-kernel mode switching was deprecated years ago with the
>>>> development of the more user friendly userspace alternatives. The
>>>> existing list of devices in usb-storage was only kept to prevent
>>>> breaking already working systems. The long term plan is to remove
>>>> the list, not to add to it. Ref:
>>>> http://permalink.gmane.org/gmane.linux.usb.general/28543
>>> [...]
>>>
>>> Can you add a comment to this effect?
>>
>> In the table in unusual_devs.h, you mean? Sure, I can do that.
>>
>> But it feels a bit strange since I can only quote and/or refer to what
>> Matthew and Greg said about the issue years ago. Putting a comment in
>> the code to remind the current maintainers about their own statements
>> could be considered out of line? Or is this appropriate here?
>>
>>
>> Bjørn
>
>
>
> --
> Matthew Dharm
> Maintainer, USB Mass Storage driver for Linux
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 04.03.2013 20:22, schrieb Bj?rn Mork:
> Matthew Dharm <[email protected]> writes:
>> The question is not one of reminding me of what I said earlier....
>> it's one of pointing people in the right direction. Frankly, some of
>> the fault for this patch lies with Greg and myself for letting it
>> through. I had just assumed that the Huawei guys had already been in
>> touch with usb-modeswitch for some reason, and that this was just an
>> optimization of existing logic (not an expansion).
I was contacted at one point by a Huawei engineer who convinced me to change the default mode-switching 'message' for all Huawei devices.
The reason was the introduction of an 'advanced' Linux driver by Huawei which requires a specific target mode. This was in October 2010.
No contact attempt since then.
>> Who is maintaining usb-modeswitch these days, anyway? The comment in
>> the file should point people directly there....
I never ceased work on it and intend to do so for years to come. I would certainly welcome any pointer to the usb_modeswitch main site in the code or the documentation. Although modem developers or engineers should not have a problem finding the site and providing new device information.
>> And, as of now, I would really like to see as many of these devices
>> migrated (albeit slowly) to using usb-modeswitch wherever possible. I
>> know there are a few devices for which that might not be possible, but
>> I am DONE dealing with this same issue over and over and over again.
>> It will certainly be work to migrate support; maybe we should wrap all
>> the relevant unusual_devs.h entires with
>> CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
>> transition period?
I think it's safe to say that usb_modeswitch is included in all distributions now. Usually, no user interaction is necessary.
> I guess the real problem will be verifying that all of the entries *can*
> go away. This type of hardware tends to get old very fast, but there is
> always someone having a really ancient device.
I will check this and add any missing USB IDs to usb_modeswitch, but I can't shake the feeling that not *all* Huawei entries in "unusual_devs.h" did actually materialize as devices ...
Anyway, as Bj?rn said, putting that initialization into the storage driver takes away quite some possibilities to handle these modems in a flexible way.
Josua Dietze
> -----Original Message-----
> From: Bjørn Mork [mailto:[email protected]]
> Sent: Monday, March 04, 2013 9:19 PM
> To: [email protected]
> Cc: [email protected]; Fangxiaozhi (Franko); Xueguiying (Zihan);
> Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
> [email protected]; [email protected]; [email protected];
> Bjørn Mork; stable
> Subject: [PATCH] USB: storage: fix Huawei mode switching regression
>
> This reverts commit 200e0d99 ("USB: storage: optimize to match the Huawei
> USB storage devices and support new switch command" and the followup
> bugfix commit cd060956 ("USB: storage: properly handle the endian issues of
> idProduct").
>
> The commit effectively added a large number of Huawei devices to the
> deprecated usb-storage mode switching logic. Many of these devices have
> been in use and supported by the userspace usb_modeswitch utility for years.
> Forcing the switching inside the kernel causes a number of regressions as a
> result of ignoring existing onfigurations, and also completely takes away the
> ability to configure mode switching per device/system/user.
------ commit 200e0d99 and commit cd060956, only put the switch command into kernel, instead of userspace usb_modeswitch utility.
------ Because in the embedded linux system, Android, or Chrome OS, etc. They don't integrate userspace usb_modeswitch utility for switching.
----- In commit 200e0d99, we send the Linux switching command to Huawei devices, so on PC Linux, you can get the largest capacity of Huawei device, including the CDROM feature. So I think this solution can meet the user's requirement in Linux.
>
> Known regressions caused by this:
> - Some of the devices support multiple modes, using different
> switching commands. There are existing configurations taking
> advantage of this.
-------But in this multiple modes, there is only one is for Linux. We don't advice the user to use the other mode not for Linux. It may cause some unexpected problem.
>
> - There is a real use case for disabling mode switching and
> instead mounting the exposed storage device. This becomes
> impossible with switching logic inside the usb-storage driver.
----In commit 200e0d99, the switching command will ask Huawei device to offer the CDROM(and /or SD) port together. After switching, users also can get the mounting storage device.
>
> - At least on device fail as a result of the usb-storage switching
> command, becoming completely unswitchable. This is possibly a
> firmware bug, but still a regression because the device work as
> expected using usb_modeswitch defaults.
----- If the kernel solution encounters this issue, then it also will occur with usb_modeswitch.
>
> In-kernel mode switching was deprecated years ago with the development of
> the more user friendly userspace alternatives. The existing list of devices in
> usb-storage was only kept to prevent breaking already working systems. The
> long term plan is to remove the list, not to add to it. Ref:
> http://permalink.gmane.org/gmane.linux.usb.general/28543
>
> Cc: <[email protected]>
> Cc: stable <[email protected]>
> Signed-off-by: Bjørn Mork <[email protected]>
> ---
> I just realized that this already had gone into maintained stable series', making
> the fix so much more urgent. This needs to be reverted before it starts
> hitting innocent distro users. So I am sending the patch now instead of
> waiting for Huawei to respond.
------ In our opinions, it is better to switch Huawei device in kernel.
------ usb_modeswitch is a tool for Linux.
------ We can not guarantee it will be integrated in all the system which integrates linux kernel. But linux kernel itself can.
>
>
> Bjørn
>
Best Regards,
Franko Fang
> drivers/usb/storage/initializers.c | 76 +--------
> drivers/usb/storage/initializers.h | 4 +-
> drivers/usb/storage/unusual_devs.h | 329
> +++++++++++++++++++++++++++++++++++-
> 3 files changed, 331 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/usb/storage/initializers.c b/drivers/usb/storage/initializers.c
> index 7ab9046..105d900 100644
> --- a/drivers/usb/storage/initializers.c
> +++ b/drivers/usb/storage/initializers.c
> @@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_data *us)
> return 0;
> }
>
> -/* This places the HUAWEI usb dongles in multi-port mode */ -static int
> usb_stor_huawei_feature_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)
> {
> int result;
>
> @@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(struct
> us_data *us)
> US_DEBUGP("Huawei mode set result is %d\n", result);
> return 0;
> }
> -
> -/*
> - * It will send a scsi switch command called rewind' to huawei dongle.
> - * When the dongle receives this command at the first time,
> - * it will reboot immediately. After rebooted, it will ignore this command.
> - * So it is unnecessary to read its response.
> - */
> -static int usb_stor_huawei_scsi_init(struct us_data *us) -{
> - int result = 0;
> - int act_len = 0;
> - struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
> - char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
> - 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> -
> - bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
> - bcbw->Tag = 0;
> - bcbw->DataTransferLength = 0;
> - bcbw->Flags = bcbw->Lun = 0;
> - bcbw->Length = sizeof(rewind_cmd);
> - memset(bcbw->CDB, 0, sizeof(bcbw->CDB));
> - memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
> -
> - result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcbw,
> - US_BULK_CB_WRAP_LEN, &act_len);
> - US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
> - return result;
> -}
> -
> -/*
> - * It tries to find the supported Huawei USB dongles.
> - * In Huawei, they assign the following product IDs
> - * for all of their mobile broadband dongles,
> - * including the new dongles in the future.
> - * So if the product ID is not included in this list,
> - * it means it is not Huawei's mobile broadband dongles.
> - */
> -static int usb_stor_huawei_dongles_pid(struct us_data *us) -{
> - struct usb_interface_descriptor *idesc;
> - int idProduct;
> -
> - idesc = &us->pusb_intf->cur_altsetting->desc;
> - idProduct = le16_to_cpu(us->pusb_dev->descriptor.idProduct);
> - /* The first port is CDROM,
> - * means the dongle in the single port mode,
> - * and a switch command is required to be sent. */
> - if (idesc && idesc->bInterfaceNumber == 0) {
> - if ((idProduct == 0x1001)
> - || (idProduct == 0x1003)
> - || (idProduct == 0x1004)
> - || (idProduct >= 0x1401 && idProduct <= 0x1500)
> - || (idProduct >= 0x1505 && idProduct <= 0x1600)
> - || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
> - return 1;
> - }
> - }
> - return 0;
> -}
> -
> -int usb_stor_huawei_init(struct us_data *us) -{
> - int result = 0;
> -
> - if (usb_stor_huawei_dongles_pid(us)) {
> - if (le16_to_cpu(us->pusb_dev->descriptor.idProduct) >= 0x1446)
> - result = usb_stor_huawei_scsi_init(us);
> - else
> - result = usb_stor_huawei_feature_init(us);
> - }
> - return result;
> -}
> diff --git a/drivers/usb/storage/initializers.h b/drivers/usb/storage/initializers.h
> index 5376d4f..529327f 100644
> --- a/drivers/usb/storage/initializers.h
> +++ b/drivers/usb/storage/initializers.h
> @@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data *us);
> * flash reader */
> int usb_stor_ucr61s2b_init(struct us_data *us);
>
> -/* This places the HUAWEI usb dongles in multi-port mode */ -int
> usb_stor_huawei_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);
> diff --git a/drivers/usb/storage/unusual_devs.h
> b/drivers/usb/storage/unusual_devs.h
> index 72923b5..d305a5a 100644
> --- a/drivers/usb/storage/unusual_devs.h
> +++ b/drivers/usb/storage/unusual_devs.h
> @@ -1527,10 +1527,335 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100,
> 0x0100,
> /* Reported by fangxiaozhi <[email protected]>
> * This brings the HUAWEI data card devices into multi-port mode
> */
> -UNUSUAL_VENDOR_INTF(0x12d1, 0x08, 0x06, 0x50,
> +UNUSUAL_DEV( 0x12d1, 0x1001, 0x0000, 0x0000,
> "HUAWEI MOBILE",
> "Mass Storage",
> - USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_init,
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1003, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1004, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1401, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1402, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1403, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1404, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1405, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1406, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1407, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1408, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1409, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140A, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140B, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140C, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140D, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140E, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x140F, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1410, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1411, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1412, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1413, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1414, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1415, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1416, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1417, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1418, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1419, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141A, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141B, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141C, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141D, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141E, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x141F, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1420, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1421, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1422, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1423, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1424, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1425, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1426, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1427, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1428, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1429, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142A, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142B, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142C, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142D, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142E, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x142F, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1430, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1431, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1432, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1433, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1434, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1435, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1436, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1437, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1438, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x1439, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143A, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143B, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143C, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143D, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143E, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> + 0),
> +UNUSUAL_DEV( 0x12d1, 0x143F, 0x0000, 0x0000,
> + "HUAWEI MOBILE",
> + "Mass Storage",
> + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
> 0),
>
> /* Reported by Vilius Bilinkevicius <vilisas AT xxx DOT lt) */
> --
> 1.7.10.4
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Dear Mork:
Thank you very much for your test.
> -----Original Message-----
> From: Bjørn Mork [mailto:[email protected]]
> Sent: Monday, March 04, 2013 7:41 PM
> To: Fangxiaozhi (Franko)
> Cc: [email protected]; [email protected]; Xueguiying
> (Zihan); Linlei (Lei Lin); [email protected]; Yili (Neil); Wangyuhua (Roger, Credit);
> Huqiao (C); [email protected]; [email protected];
> [email protected]
> Subject: v3.8 regression: Huawei mode switching fails (was Re: [PATCH
> 2/2]linux-usb:optimize to match the Huawei USB storage devices and support
> new switch command)
>
> Hello Franko,
>
> This patch causes a number of regressions for both the Huawei devices I have
> available for testing. One of them is completely unusable in v3.8 (unable to
> switch to modem mode) unless the usb-storage driver is disabled.
------Which device, can you tell me more information?
------Which model? And what's its firmware version?
>
> I realize that some devices are historically handled by the usb-storage driver,
> but userspace modeswitching is the rule for new devices AFAIK.
> I see absolutely no valid argument for adding new devices. And there is
> absolutely no excuse for adding devices which have been handled by
> userspace switching for years! The patch does not just "optimize"
> matching. It adds a large number of devices which were previously handled
> just fine by usb_modeswitch. This is guaranteed to confuse users with existing
> configurations, and users looking up any of the existing documentation
> pointing to usb_modeswitch.
------Yes. But there is some problems for this:
1. As far as I know, usb_modeswitch is now only integrated in the PC Linux. It isn't integrated to other system with linux kernel, such as Android, Chrome OS, etc. On these system, how can we switch the device?
2. usb_modeswitch often sends the Windows switching command to switch Huawei device, but not sends Linux switching command. This maybe causes some unexpected problem.
>
> There is no need to repeat the discussion of kernel vs userspace switching. I
> will only note that userspace switching:
> - has been selected as the rule for new devices,
> - allow the user to temporarily disable switching e.g. for mounting and
> inspecting the usb-storage exported data,
> - allow the user/system to apply device specific switching quirks
>
>
> The v3.7->v3.8 regressions I observe are:
>
> 1) Temporarily disabling mode switching and mounting the CD image is now
> impossible. Mode switching can only be disabled by blacklisting
> usb-storage, which of course prevents usb-storage from working
>
> Prior to v3.8, modeswitching could easily be disabled by userspace
> configuration. The change breaks existing configurations.
>
> 2) Switching to non-default modes is now impossible. The E392 (initially
> appearing as 12d1:1505) Windows drivers will use a different command than
> the one used by Linux, causing the device to select a different configuration
> in Linux and Windows. This forces Linux and Windows to see the device
> differently.
>
> Prior to v3.8, different modeswitching commands could be configured per
> device. The change breaks existing configurations.
>
> 3) Switching fails for some devices. The E367 (initially appearing as
> 12d1:1446) does not switch when it receives the command sent by
> usb-storage. But the command disable further switching, preventing
> userspace switching from working as well.
>
> Prior to v3.8, the device would switch fine using a default usb_modeswitch
> configuration. The change breaks existing configurations.
>
> I do note that there is a slight difference between the known working
> usb_modeswitch command:
>
>
> 55534243123456780000000000000011062000000100000000000000000000
>
> and the command sent by usb-storage:
>
> char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
> 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
>
> I assume the cause of the failure is either this difference or some timing
> issue.
>
> Anyway, I believe this patch must be reverted. It disables currently used, well
> documented, and extremely useful, userspace funtionaliy for all devices
> implicitly added by the conversion from device matching to vendor matching.
>
>
>
> Bjørn
Best Regards,
Franko Fang
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Monday 04 March 2013 23:28:47 Josua Dietze wrote:
> > I guess the real problem will be verifying that all of the entries can
> > go away. This type of hardware tends to get old very fast, but there is
> > always someone having a really ancient device.
>
> I will check this and add any missing USB IDs to usb_modeswitch, but I can't shake the feeling that not all Huawei entries in "unusual_devs.h" did actually materialize as devices ...
>
> Anyway, as Bj?rn said, putting that initialization into the storage driver takes away quite some possibilities to handle these modems in a flexible way.
But it adds the ability to handle loss of power in the suspend case
cleanly. As long as the switch only makes additional devices appear,
doing it in kernel space is the nicer approach.
Regards
Oliver
On Tuesday 05 March 2013 02:28:07 Fangxiaozhi wrote:
Hi,
> 1. As far as I know, usb_modeswitch is now only integrated in the PC Linux. It isn't integrated to other system with linux kernel, such as Android, Chrome OS, etc. On these system, how can we switch the device?
Then those systems will have to add modeswitch.
If we are to do mode switching in kernel space, there has to be
an additional technical benefit over the existing and well working solution
in user space.
> 2. usb_modeswitch often sends the Windows switching command to switch Huawei device, but not sends Linux switching command. This maybe causes some unexpected problem.
You have two commands? What is the difference? Anyway, if usb_modeswitch
has issues, these problems need to be fixed.
Independent from that, there is a problem with user space mode switching.
Namely it doesn't work with reset_resume(). Thus we cannot do sane S4
with the user space solution.
However, the problem cannot be solved by merely by adding the switch
to the storage driver.
Regards
Oliver
Dear Oliver:
> -----Original Message-----
> From: Oliver Neukum [mailto:[email protected]]
> Sent: Tuesday, March 05, 2013 4:49 PM
> To: Fangxiaozhi (Franko)
> Cc: Bjørn Mork; [email protected]; [email protected];
> Xueguiying (Zihan); Linlei (Lei Lin); [email protected]; Yili (Neil); Wangyuhua
> (Roger, Credit); Huqiao (C); [email protected]; [email protected];
> [email protected]
> Subject: Re: v3.8 regression: Huawei mode switching fails (was Re: [PATCH
> 2/2]linux-usb:optimize to match the Huawei USB storage devices and support
> new switch command)
>
> On Tuesday 05 March 2013 02:28:07 Fangxiaozhi wrote:
>
> Hi,
>
> > 1. As far as I know, usb_modeswitch is now only integrated in the PC Linux.
> It isn't integrated to other system with linux kernel, such as Android, Chrome
> OS, etc. On these system, how can we switch the device?
>
> Then those systems will have to add modeswitch.
> If we are to do mode switching in kernel space, there has to be an additional
> technical benefit over the existing and well working solution in user space.
-----The vendor doesn't want to add the modeswitch on their system. We try to push them to do it, but they don't agree.
>
> > 2. usb_modeswitch often sends the Windows switching command to
> switch Huawei device, but not sends Linux switching command. This maybe
> causes some unexpected problem.
>
> You have two commands? What is the difference? Anyway, if usb_modeswitch
> has issues, these problems need to be fixed.
------Sorry, it is one command, but with different values in it for different system, such as:
1. For Windows:
{0x11, 0x06, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
2. For Mac OS:
{0x11, 0x06, 0x10, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
3. For Linux:
{0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
Sometimes, modeswitch will send the command for Windows to device on Linux system, but not the command for Linux.
>
> Independent from that, there is a problem with user space mode switching.
> Namely it doesn't work with reset_resume(). Thus we cannot do sane S4 with
> the user space solution.
> However, the problem cannot be solved by merely by adding the switch to the
> storage driver.
-----For this issue, can you offer more details? And we can try to solve it together.
>
> Regards
> Oliver
Best Regards,
Franko Fang
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
"Fangxiaozhi (Franko)" <[email protected]> writes:
> ------ commit 200e0d99 and commit cd060956, only put the switch
> command into kernel, instead of userspace usb_modeswitch utility.
Yes. And that is the problem. It was agreed years ago that this
functionality belongs in userspace. Ref e.g
https://lkml.org/lkml/2009/12/15/332
https://lkml.org/lkml/2010/4/19/216
https://lkml.org/lkml/2012/2/28/569
Please note the re-occurrence of this discussion, despite the fact that
Matthew's message from 2009 should be quite clear.
> ------ Because in the embedded linux system, Android, or Chrome OS,
> etc. They don't integrate userspace usb_modeswitch utility for
> switching.
Why not? If they can upgrade the kernel, then they most certainly can
install a userspace utility.
There is no excuse for an embedded system to do this differently.
Please see e.g. OpenWRT as an example of an embedded system doing this
correctly.
> ----- In commit 200e0d99, we send the Linux switching command to
> Huawei devices, so on PC Linux, you can get the largest capacity of
> Huawei device, including the CDROM feature. So I think this solution
> can meet the user's requirement in Linux.
No, it does not. Some users have already configured their system to
disable switching or to switch using a different message. The patch
does not address this at all.
>> Known regressions caused by this:
>> - Some of the devices support multiple modes, using different
>> switching commands. There are existing configurations taking
>> advantage of this.
>
> -------But in this multiple modes, there is only one is for Linux. We
> don't advice the user to use the other mode not for Linux. It may
> cause some unexpected problem.
Although I do not agree with this, I do not argue that the Linux
defaults should change. The point is that this was configurable prior
to the patch and it is not after. This is a regression for any user who
has deliberately chosen to use the Windows mode.
Wrt the Linux vs Windows modes: We all appreciate the work from Huawei
trying to support Linux in the best possible way. But implementing
special firmware modes for Linux is not necessarily best for Linux. We
do have some experience with system BIOSes implementing special hooks
for Linux, and they usually add more problems than they solve. It is
very easy for Linux to resemble whatever Windows does when talking to
hardware, and that is the method that has proven to work best.
Ref for example this comment in drivers/acpi/acpica/utosi.c :
/*
* Strings supported by the _OSI predefined control method (which is
* implemented internally within this module.)
*
* March 2009: Removed "Linux" as this host no longer wants to respond true
* for this string. Basically, the only safe OS strings are windows-related
* and in many or most cases represent the only test path within the
* BIOS-provided ASL code.
*
* The last element of each entry is used to track the newest version of
* Windows that the BIOS has requested.
*/
>>
>> - There is a real use case for disabling mode switching and
>> instead mounting the exposed storage device. This becomes
>> impossible with switching logic inside the usb-storage driver.
>
> ----In commit 200e0d99, the switching command will ask Huawei device
> to offer the CDROM(and /or SD) port together. After switching, users
> also can get the mounting storage device.
Yes, I understand that the firmware does this by default. But you also
have (unsupported and undocumented) ways of disabling this. Some users
do that. Some users may also want to mount the device before switching
for other reasons.
The fact that your firmware lets the user mount the CD after switch does
not completely prevent some users from wanting to mount it before
switching.
>>
>> - At least on device fail as a result of the usb-storage switching
>> command, becoming completely unswitchable. This is possibly a
>> firmware bug, but still a regression because the device work as
>> expected using usb_modeswitch defaults.
>
> ----- If the kernel solution encounters this issue, then it also will
> occur with usb_modeswitch.
Well, it does not. Blacklisting usb-storage works around the issue.
The command sent by usb-storage makes the firmware reset once, but it
appears with the exact same identity as before. This makes usb-storage
repeat the switch command, which now has no effect. Then usb_modeswitch
tries, but is refused.
switches from:
Mar 5 10:23:20 nemi kernel: [46342.029477] USB Mass Storage support registered.
Mar 5 10:23:57 nemi kernel: [46378.704337] usb 7-1: new high-speed USB device number 34 using ehci-pci
Mar 5 10:23:57 nemi kernel: [46378.842526] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446
Mar 5 10:23:57 nemi kernel: [46378.842542] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5
Mar 5 10:23:57 nemi kernel: [46378.842552] usb 7-1: Product: HUAWEI MBIM Device
Mar 5 10:23:57 nemi kernel: [46378.842560] usb 7-1: Manufacturer: Huawei Technologies
Mar 5 10:23:57 nemi kernel: [46378.842569] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
to:
Mar 5 10:24:01 nemi kernel: [46382.924327] usb 7-1: new high-speed USB device number 35 using ehci-pci
Mar 5 10:24:01 nemi kernel: [46383.063590] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446
Mar 5 10:24:01 nemi kernel: [46383.063606] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5
Mar 5 10:24:01 nemi kernel: [46383.063615] usb 7-1: Product: HUAWEI MBIM Device
Mar 5 10:24:01 nemi kernel: [46383.063624] usb 7-1: Manufacturer: Huawei Technologies
Mar 5 10:24:01 nemi kernel: [46383.063633] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
The 3 commands sent (not the difference in the last one from usb_modeswitch):
ffff8802306ef900 2477597193 S Bo:7:034:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01010001 00000000 000000
ffff8802306ef900 2477597881 C Bo:7:034:1 0 31 >
ffff8802306ef900 2481816603 S Bo:7:035:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01010001 00000000 000000
ffff8802306ef900 2481816802 C Bo:7:035:1 0 31 >
ffff8802306ef900 2482455758 S Bo:7:035:1 -115 31 = 55534243 12345678 00000000 00000011 06200000 01000000 00000000 000000
ffff8802306ef900 2485457009 C Bo:7:035:1 -2 0
Changing the command embedded in drivers/usb/storage/initializers.c to
resemble the default from usb_modeswitch makes the in-kernel switching
work for this device. But we do not know the effect on other devices.
And this kind of workarounds is not something you can easily make any
user do in the kernel, while it is a simple configuration file or
command line option in usb_modeswitch.
this diff on top of v3.8.2:
bjorn@nemi:/usr/local/src/git/linux$ git diff
diff --git a/drivers/usb/storage/initializers.c b/drivers/usb/storage/initializers.c
index 7ab9046..6869415 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -116,8 +116,8 @@ static int usb_stor_huawei_scsi_init(struct us_data *us)
int result = 0;
int act_len = 0;
struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
- char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
bcbw->Tag = 0;
results in:
ffff880221402440 3307649125 S Bo:7:040:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01000000 00000000 000000
ffff880221402440 3307649322 C Bo:7:040:1 0 31 >
which switches from:
Mar 5 10:37:47 nemi kernel: [47208.756338] usb 7-1: new high-speed USB device number 40 using ehci-pci
Mar 5 10:37:47 nemi kernel: [47208.893231] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446
Mar 5 10:37:47 nemi kernel: [47208.893245] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5
Mar 5 10:37:47 nemi kernel: [47208.893254] usb 7-1: Product: HUAWEI MBIM Device
Mar 5 10:37:47 nemi kernel: [47208.893263] usb 7-1: Manufacturer: Huawei Technologies
Mar 5 10:37:47 nemi kernel: [47208.893272] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
to:
Mar 5 10:37:51 nemi kernel: [47212.880322] usb 7-1: new high-speed USB device number 41 using ehci-pci
Mar 5 10:37:51 nemi kernel: [47213.016734] usb 7-1: New USB device found, idVendor=12d1, idProduct=1506
Mar 5 10:37:51 nemi kernel: [47213.016748] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5
Mar 5 10:37:51 nemi kernel: [47213.016757] usb 7-1: Product: HUAWEI MBIM Device
Mar 5 10:37:51 nemi kernel: [47213.016766] usb 7-1: Manufacturer: Huawei Technologies
Mar 5 10:37:51 nemi kernel: [47213.016774] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Mar 5 10:37:51 nemi kernel: [47213.016816] device: '7-1': device_add
As I said, I am fully aware that this might be a firmware issue. The
firmware of this device is probably not meant for production, and there
is a possibility that it is unavailable to the general public.
But the point is still that such issues may occur, and that working
around them in userspace is a simple configuration matter. That's one
important reason to keep this in userspace.
> ------ In our opinions, it is better to switch Huawei device in
> kernel.
> ------ usb_modeswitch is a tool for Linux.
> ------ We can not guarantee it will be integrated in all the system
> which integrates linux kernel. But linux kernel itself can.
The device also needs a userspace application to configure, connect and
monitor it. Should we put that into the kernel as well? Nope.
These devices will not work without userspace support. Fix the distros
instead if they lack proper userspace mode switching support.
Bjørn
Oliver Neukum <[email protected]> writes:
> On Monday 04 March 2013 23:28:47 Josua Dietze wrote:
>> > I guess the real problem will be verifying that all of the entries can
>> > go away. This type of hardware tends to get old very fast, but there is
>> > always someone having a really ancient device.
>>
>> I will check this and add any missing USB IDs to usb_modeswitch, but I can't shake the feeling that not all Huawei entries in "unusual_devs.h" did actually materialize as devices ...
>>
>> Anyway, as Bjørn said, putting that initialization into the storage
>> driver takes away quite some possibilities to handle these modems in
>> a flexible way.
>
> But it adds the ability to handle loss of power in the suspend case
> cleanly.
How is that different? If the device loses power, then it will appear
as a new unswitched USB storage device, and go through the switching
sequence again. And if the device does not lose power but the system
does, then it will appear as a new, already switched, USB modem device.
The system behaviour will be exactly the same AFAICS, providing the
switching command is the same.
> As long as the switch only makes additional devices appear,
> doing it in kernel space is the nicer approach.
You cannot guarantee this. Huawei may not support it, but there are
instructions around the net on how to change this.
And how do you want this to play together with complex devices having
multiple configurations, where one of those is mode switching and the
other is not? Yes, there are Huawei devices like that.
The firmware implement a wide variety of different alternative
configurations. Some users take advantage of that. Doing the mode
switching in the kernel removes all but one of these alternatives. The
fact that the one Windows uses is among those removed is IMHO bad,
regardless of whether Huawei support that mode on Linux.
Bjørn
On Tuesday 05 March 2013 11:07:05 Bj?rn Mork wrote:
> "Fangxiaozhi (Franko)" <[email protected]> writes:
>
> > ------ commit 200e0d99 and commit cd060956, only put the switch
> > command into kernel, instead of userspace usb_modeswitch utility.
>
> Yes. And that is the problem. It was agreed years ago that this
> functionality belongs in userspace. Ref e.g
> https://lkml.org/lkml/2009/12/15/332
> https://lkml.org/lkml/2010/4/19/216
> https://lkml.org/lkml/2012/2/28/569
>
> Please note the re-occurrence of this discussion, despite the fact that
> Matthew's message from 2009 should be quite clear.
Since 2009 the facts have been changing. Basically we are encountering
two trends
1. Power save has become more important
2. We are seeing devices that are switchable, yet include interfaces other
than communication and virtual storage, foremost real storage in the
form of a microSD-reader
Whenever we cut power to a switchable device it reverts to the power-on
state. That involves not only the communication functionality (which we
could live with, as it cannot handle loss of power anyway) but also other
interfaces. In addition we need to deal with resets which may or may not
make the device revert to power-on
This is a basic problem of the design. If you want reset_resume() for power
loss to work you need to do it in kernel space for the same reason we restore
the configuration in kernel space before we rebind the drivers and before
we thaw user space.
However, this argues not for doing the switch simply in the storage driver
but to switch in the core.
Regards
Oliver
"Fangxiaozhi (Franko)" <[email protected]> writes:
> ------Sorry, it is one command, but with different values in it for different system, such as:
> 1. For Windows:
> {0x11, 0x06, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00,
> - 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> 2. For Mac OS:
> {0x11, 0x06, 0x10, 0x00, 0x00, 0x01, 0x01, 0x00,
> - 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
> 3. For Linux:
> {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
> - 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
I may be wrong, but my gut feeling is that these command only change the
descriptors and does nothing to the underlying device functions. None
of the experiments I have done with the Windows vs Linux mode for
qmi_wwan have revealed any differences apart from
endpoint to interface allocation:
Linux mode use split the control endpoint and data endpoints in
separate interfaces for the network function, while Windows mode put
all three endpoints in the same interface.
additional functional descriptors:
Linux (and MAC) mode adds a few CDC descriptors (although the class
is vendor specific). The most visible effect is a device specific MAC
address. Note that there is no real need for this, however. It is
only used on a point-to-point link between the device and host, and a
random address works just as fine.
In fact, there have been several reports of problems due to this,
because some firmwares specify the device MAC address in the
descriptor. This causes Linux to ignore frames from the device
unless the user manually override the interface address.
This is IMHO an excellent example of the types of bugs a separate
Linux mode will cause. This issue would of course never have
existed if it affected the Windows mode.
Ref http://lists.debian.org/debian-kernel/2012/06/msg00599.html
As you are well aware of, we parse descriptors as needed on Linux and
can just as easy support the Windows look'n'feel if required. There is
absolutely no need to create special Linux descriptors to adapt to
existing drivers. We'll rather fix the drivers than using a mode which
isn't tested by the Windows users.
Just to illustrate for interested readers with no Huawei device to test,
these are the resulting descriptor for all three commands on my two
Huawei devices (using a hacked lsusb version decoding CDC functional
descriptors for vendor specific interfaces):
E392u-12:
1. For Windows:
usb_modeswitch -v 12d1 -p 1505 -W -M 55534243000000000000000000000011060000000101000100000000000000
Bus 007 Device 043: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 3 Huawei Technologies
iProduct 2 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 161
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 1 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 16
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 18
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 19
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 17
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
2. For Mac OS:
usb_modeswitch -v 12d1 -p 1505 -W -M 55534243000000000000000000000011061000000101000100000000000000
Bus 007 Device 045: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 4 Huawei Technologies
iProduct 3 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 193
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 2 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 9
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Ethernet:
iMacAddress 1 00A0C6000000
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1544
wNumberMCFilters 0x0001
bNumberPowerFilters 0
CDC Union:
bMasterInterface 3
bSlaveInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 8
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
3. For Linux:
usb_modeswitch -v 12d1 -p 1505 -W -M 55534243000000000000000000000011062000000101000100000000000000
Bus 007 Device 047: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 4 Huawei Technologies
iProduct 3 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 193
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 2 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 9
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Ethernet:
iMacAddress 1 00A0C6000000
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1544
wNumberMCFilters 0x0001
bNumberPowerFilters 0
CDC Union:
bMasterInterface 3
bSlaveInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 8
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
E367u-2 (had to modify the given commands slightly to make the device switch):
1. For Windows:
usb_modeswitch -v 12d1 -p 1446 -W -M 55534243000000000000000000000011060000000100000000000000000000
Bus 007 Device 051: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 32
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 3 Huawei Technologies
iProduct 2 HUAWEI MBIM Device
iSerial 4 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 161
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 1 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 7
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 32
bDeviceProtocol 1
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
2. For Mac OS:
usb_modeswitch -v 12d1 -p 1446 -W -M 55534243000000000000000000000011061000000100000000000000000000
Bus 007 Device 053: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 4 Huawei Technologies
iProduct 3 HUAWEI MBIM Device
iSerial 5 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 201
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 2 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 3
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 0
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 9
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Ethernet:
iMacAddress 1 0250f3000000
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1544
wNumberMCFilters 0x0001
bNumberPowerFilters 0
CDC Union:
bMasterInterface 3
bSlaveInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 8
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
3. For Linux:
usb_modeswitch -v 12d1 -p 1446 -W -M 55534243000000000000000000000011062000000100000000000000000000
Bus 007 Device 055: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 4 Huawei Technologies
iProduct 3 HUAWEI MBIM Device
iSerial 5 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 201
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 2 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 3
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 0
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 9
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Ethernet:
iMacAddress 1 0250f3000000
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1544
wNumberMCFilters 0x0001
bNumberPowerFilters 0
CDC Union:
bMasterInterface 3
bSlaveInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 8
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
AFAICS, there is absolutely no difference between the "MAC mode" and
"Linux mode" for these two devices. And the only differences between
the "Windows mode" and the two others are those I described above. Note
in particular that all end point descriptors are identical in all three
modes. FWIW, the option and qmi_wwan drivers will handle all modes
equally well. There is absolutely no advantage to either mode. The
only visible difference will be the wwanX interface MAC address.
Bjørn
Oliver Neukum <[email protected]> writes:
> On Tuesday 05 March 2013 11:07:05 Bjørn Mork wrote:
>> "Fangxiaozhi (Franko)" <[email protected]> writes:
>>
>> > ------ commit 200e0d99 and commit cd060956, only put the switch
>> > command into kernel, instead of userspace usb_modeswitch utility.
>>
>> Yes. And that is the problem. It was agreed years ago that this
>> functionality belongs in userspace. Ref e.g
>> https://lkml.org/lkml/2009/12/15/332
>> https://lkml.org/lkml/2010/4/19/216
>> https://lkml.org/lkml/2012/2/28/569
>>
>> Please note the re-occurrence of this discussion, despite the fact that
>> Matthew's message from 2009 should be quite clear.
>
> Since 2009 the facts have been changing. Basically we are encountering
> two trends
>
> 1. Power save has become more important
> 2. We are seeing devices that are switchable, yet include interfaces other
> than communication and virtual storage, foremost real storage in the
> form of a microSD-reader
This changed with Windows8. You will see _less_ switchable devices in
the future. Mode switching is now considered legacy functionality
intended for OSes released before 2012.
> Whenever we cut power to a switchable device it reverts to the power-on
> state. That involves not only the communication functionality (which we
> could live with, as it cannot handle loss of power anyway) but also other
> interfaces. In addition we need to deal with resets which may or may not
> make the device revert to power-on
>
> This is a basic problem of the design. If you want reset_resume() for power
> loss to work you need to do it in kernel space for the same reason we restore
> the configuration in kernel space before we rebind the drivers and before
> we thaw user space.
>
> However, this argues not for doing the switch simply in the storage driver
> but to switch in the core.
OK, I think I understand. You really want us to completely ignore the
unswitched mode and just seemlessly restore the switched mode, the same
way we just silently fetch the device descriptor and restore the
configuration.
Well, that does sound interesting. But I don't think we want the tables
hard coded in the USB core? Maybe a new userspace ABI or a new driver API?
I am not sure this is worth it though. The "other OS" does not support
this either. Microsoft's solution to the problem is getting rid of the
whole mode switching hell, requiring the devices to support MBIM in
their default mode. I believe we are better off working on improving
the MBIM userspace support than trying to work around this self imposed
firmware issue.
Bjørn
Hello Mork,
>> ------ Because in the embedded linux system, Android, or Chrome OS,
>> etc. They don't integrate userspace usb_modeswitch utility for
>> switching.
>Why not? If they can upgrade the kernel, then they most certainly can install a userspace utility.
>There is no excuse for an embedded system to do this differently.
>Please see e.g. OpenWRT as an example of an embedded system doing this correctly.
But currently Android and Chrome OS has not integrated the usb_modeswitch utility.
>From a vendor's point of view, our purpose is to make our devices be supported natively by those OS.
So we consider that add the switch function to the kernel resolves the problem from the source.
Then this function will be inherited by Android & Chrome OS.
Regards,
Lin Lei
-----邮件原件-----
发件人: Bjørn Mork [mailto:[email protected]]
发送时间: 2013年3月5日 18:07
收件人: Fangxiaozhi (Franko)
抄送: [email protected]; [email protected]; Xueguiying (Zihan); Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); [email protected]; [email protected]; [email protected]; stable
主题: Re: [PATCH] USB: storage: fix Huawei mode switching regression
"Fangxiaozhi (Franko)" <[email protected]> writes:
> ------ commit 200e0d99 and commit cd060956, only put the switch
> command into kernel, instead of userspace usb_modeswitch utility.
Yes. And that is the problem. It was agreed years ago that this functionality belongs in userspace. Ref e.g
https://lkml.org/lkml/2009/12/15/332
https://lkml.org/lkml/2010/4/19/216
https://lkml.org/lkml/2012/2/28/569
Please note the re-occurrence of this discussion, despite the fact that Matthew's message from 2009 should be quite clear.
> ------ Because in the embedded linux system, Android, or Chrome OS,
> etc. They don't integrate userspace usb_modeswitch utility for
> switching.
Why not? If they can upgrade the kernel, then they most certainly can install a userspace utility.
There is no excuse for an embedded system to do this differently.
Please see e.g. OpenWRT as an example of an embedded system doing this correctly.
> ----- In commit 200e0d99, we send the Linux switching command to
> Huawei devices, so on PC Linux, you can get the largest capacity of
> Huawei device, including the CDROM feature. So I think this solution
> can meet the user's requirement in Linux.
No, it does not. Some users have already configured their system to disable switching or to switch using a different message. The patch does not address this at all.
>> Known regressions caused by this:
>> - Some of the devices support multiple modes, using different
>> switching commands. There are existing configurations taking
>> advantage of this.
>
> -------But in this multiple modes, there is only one is for Linux. We
> don't advice the user to use the other mode not for Linux. It may
> cause some unexpected problem.
Although I do not agree with this, I do not argue that the Linux defaults should change. The point is that this was configurable prior to the patch and it is not after. This is a regression for any user who has deliberately chosen to use the Windows mode.
Wrt the Linux vs Windows modes: We all appreciate the work from Huawei trying to support Linux in the best possible way. But implementing special firmware modes for Linux is not necessarily best for Linux. We do have some experience with system BIOSes implementing special hooks for Linux, and they usually add more problems than they solve. It is very easy for Linux to resemble whatever Windows does when talking to hardware, and that is the method that has proven to work best.
Ref for example this comment in drivers/acpi/acpica/utosi.c :
/*
* Strings supported by the _OSI predefined control method (which is
* implemented internally within this module.)
*
* March 2009: Removed "Linux" as this host no longer wants to respond true
* for this string. Basically, the only safe OS strings are windows-related
* and in many or most cases represent the only test path within the
* BIOS-provided ASL code.
*
* The last element of each entry is used to track the newest version of
* Windows that the BIOS has requested.
*/
>>
>> - There is a real use case for disabling mode switching and
>> instead mounting the exposed storage device. This becomes
>> impossible with switching logic inside the usb-storage driver.
>
> ----In commit 200e0d99, the switching command will ask Huawei device
> to offer the CDROM(and /or SD) port together. After switching, users
> also can get the mounting storage device.
Yes, I understand that the firmware does this by default. But you also have (unsupported and undocumented) ways of disabling this. Some users do that. Some users may also want to mount the device before switching for other reasons.
The fact that your firmware lets the user mount the CD after switch does not completely prevent some users from wanting to mount it before switching.
>>
>> - At least on device fail as a result of the usb-storage switching
>> command, becoming completely unswitchable. This is possibly a
>> firmware bug, but still a regression because the device work as
>> expected using usb_modeswitch defaults.
>
> ----- If the kernel solution encounters this issue, then it also will
> occur with usb_modeswitch.
Well, it does not. Blacklisting usb-storage works around the issue.
The command sent by usb-storage makes the firmware reset once, but it appears with the exact same identity as before. This makes usb-storage repeat the switch command, which now has no effect. Then usb_modeswitch tries, but is refused.
switches from:
Mar 5 10:23:20 nemi kernel: [46342.029477] USB Mass Storage support registered.
Mar 5 10:23:57 nemi kernel: [46378.704337] usb 7-1: new high-speed USB device number 34 using ehci-pci Mar 5 10:23:57 nemi kernel: [46378.842526] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446 Mar 5 10:23:57 nemi kernel: [46378.842542] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5 Mar 5 10:23:57 nemi kernel: [46378.842552] usb 7-1: Product: HUAWEI MBIM Device Mar 5 10:23:57 nemi kernel: [46378.842560] usb 7-1: Manufacturer: Huawei Technologies Mar 5 10:23:57 nemi kernel: [46378.842569] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
to:
Mar 5 10:24:01 nemi kernel: [46382.924327] usb 7-1: new high-speed USB device number 35 using ehci-pci Mar 5 10:24:01 nemi kernel: [46383.063590] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446 Mar 5 10:24:01 nemi kernel: [46383.063606] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5 Mar 5 10:24:01 nemi kernel: [46383.063615] usb 7-1: Product: HUAWEI MBIM Device Mar 5 10:24:01 nemi kernel: [46383.063624] usb 7-1: Manufacturer: Huawei Technologies Mar 5 10:24:01 nemi kernel: [46383.063633] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
The 3 commands sent (not the difference in the last one from usb_modeswitch):
ffff8802306ef900 2477597193 S Bo:7:034:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01010001 00000000 000000
ffff8802306ef900 2477597881 C Bo:7:034:1 0 31 >
ffff8802306ef900 2481816603 S Bo:7:035:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01010001 00000000 000000
ffff8802306ef900 2481816802 C Bo:7:035:1 0 31 >
ffff8802306ef900 2482455758 S Bo:7:035:1 -115 31 = 55534243 12345678 00000000 00000011 06200000 01000000 00000000 000000
ffff8802306ef900 2485457009 C Bo:7:035:1 -2 0
Changing the command embedded in drivers/usb/storage/initializers.c to resemble the default from usb_modeswitch makes the in-kernel switching work for this device. But we do not know the effect on other devices.
And this kind of workarounds is not something you can easily make any user do in the kernel, while it is a simple configuration file or command line option in usb_modeswitch.
this diff on top of v3.8.2:
bjorn@nemi:/usr/local/src/git/linux$ git diff diff --git a/drivers/usb/storage/initializers.c b/drivers/usb/storage/initializers.c
index 7ab9046..6869415 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -116,8 +116,8 @@ static int usb_stor_huawei_scsi_init(struct us_data *us)
int result = 0;
int act_len = 0;
struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
- char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
bcbw->Tag = 0;
results in:
ffff880221402440 3307649125 S Bo:7:040:1 -115 31 = 55534243 00000000 00000000 00001011 06200000 01000000 00000000 000000
ffff880221402440 3307649322 C Bo:7:040:1 0 31 >
which switches from:
Mar 5 10:37:47 nemi kernel: [47208.756338] usb 7-1: new high-speed USB device number 40 using ehci-pci Mar 5 10:37:47 nemi kernel: [47208.893231] usb 7-1: New USB device found, idVendor=12d1, idProduct=1446 Mar 5 10:37:47 nemi kernel: [47208.893245] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5 Mar 5 10:37:47 nemi kernel: [47208.893254] usb 7-1: Product: HUAWEI MBIM Device Mar 5 10:37:47 nemi kernel: [47208.893263] usb 7-1: Manufacturer: Huawei Technologies Mar 5 10:37:47 nemi kernel: [47208.893272] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
to:
Mar 5 10:37:51 nemi kernel: [47212.880322] usb 7-1: new high-speed USB device number 41 using ehci-pci Mar 5 10:37:51 nemi kernel: [47213.016734] usb 7-1: New USB device found, idVendor=12d1, idProduct=1506 Mar 5 10:37:51 nemi kernel: [47213.016748] usb 7-1: New USB device strings: Mfr=4, Product=3, SerialNumber=5 Mar 5 10:37:51 nemi kernel: [47213.016757] usb 7-1: Product: HUAWEI MBIM Device Mar 5 10:37:51 nemi kernel: [47213.016766] usb 7-1: Manufacturer: Huawei Technologies Mar 5 10:37:51 nemi kernel: [47213.016774] usb 7-1: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ Mar 5 10:37:51 nemi kernel: [47213.016816] device: '7-1': device_add
As I said, I am fully aware that this might be a firmware issue. The firmware of this device is probably not meant for production, and there is a possibility that it is unavailable to the general public.
But the point is still that such issues may occur, and that working around them in userspace is a simple configuration matter. That's one important reason to keep this in userspace.
> ------ In our opinions, it is better to switch Huawei device in
> kernel.
> ------ usb_modeswitch is a tool for Linux.
> ------ We can not guarantee it will be integrated in all the system
> which integrates linux kernel. But linux kernel itself can.
The device also needs a userspace application to configure, connect and monitor it. Should we put that into the kernel as well? Nope.
These devices will not work without userspace support. Fix the distros instead if they lack proper userspace mode switching support.
Bjørn
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tue, Mar 05, 2013 at 01:23:33PM +0100, Bj?rn Mork wrote:
> As you are well aware of, we parse descriptors as needed on Linux and
> can just as easy support the Windows look'n'feel if required. There is
> absolutely no need to create special Linux descriptors to adapt to
> existing drivers. We'll rather fix the drivers than using a mode which
> isn't tested by the Windows users.
I totally agree with this, and this is the way the rest of Linux works.
There should not be any difference in the hardware descriptors between
operating systems.
If Linux isn't working properly for some hardware, we will fix it, do
not work around Linux issues (perceived or real) in hardware.
Bj?rn, thanks for catching this kernel change, I'll revert it and push
the changes to the stable kernel releases. It was my fault to not
notice this bug, my apologies.
greg k-h
On Wed, Mar 06, 2013 at 01:34:44AM +0000, Linlei (Lei Lin) wrote:
> Hello Mork,
>
> >> ------ Because in the embedded linux system, Android, or Chrome OS,
> >> etc. They don't integrate userspace usb_modeswitch utility for
> >> switching.
>
> >Why not? If they can upgrade the kernel, then they most certainly can install a userspace utility.
>
> >There is no excuse for an embedded system to do this differently.
> >Please see e.g. OpenWRT as an example of an embedded system doing this correctly.
>
> But currently Android and Chrome OS has not integrated the
> usb_modeswitch utility.
That is not a kernel problem. I find it hard to believe that Chrome OS
would not gladly accept code to resolve this issue, can't you put it
into the modemmanager or whatever Chrome OS uses to handle their
wireless modems?
As for Android, sorry, you are on your own, you will just have to deal
with the individual OEMs that are incorporating your hardware :(
> From a vendor's point of view, our purpose is to make our devices be
> supported natively by those OS.
We have a solution, usb_modeswitch, any user should be using that.
> So we consider that add the switch function to the kernel resolves the
> problem from the source.
> Then this function will be inherited by Android & Chrome OS.
Don't circumvent horribly governed userspace projects by getting changes
into the Linux kernel. Go fix those projects instead.
Good luck,
greg k-h
On Wed, 2013-03-06 at 09:44 +0800, Greg KH wrote:
> On Wed, Mar 06, 2013 at 01:34:44AM +0000, Linlei (Lei Lin) wrote:
> > Hello Mork,
> >
> > >> ------ Because in the embedded linux system, Android, or Chrome OS,
> > >> etc. They don't integrate userspace usb_modeswitch utility for
> > >> switching.
> >
> > >Why not? If they can upgrade the kernel, then they most certainly can install a userspace utility.
> >
> > >There is no excuse for an embedded system to do this differently.
> > >Please see e.g. OpenWRT as an example of an embedded system doing this correctly.
> >
> > But currently Android and Chrome OS has not integrated the
> > usb_modeswitch utility.
>
> That is not a kernel problem. I find it hard to believe that Chrome OS
> would not gladly accept code to resolve this issue, can't you put it
> into the modemmanager or whatever Chrome OS uses to handle their
> wireless modems?
They use ModemManager, and that's still not the best place to put
modeswitching. The best place to modeswitch anything is usb_modeswitch.
No sense duplicating the functionality that usb_modeswitch already
supplies.
Dan
>
> As for Android, sorry, you are on your own, you will just have to deal
> with the individual OEMs that are incorporating your hardware :(
>
> > From a vendor's point of view, our purpose is to make our devices be
> > supported natively by those OS.
>
> We have a solution, usb_modeswitch, any user should be using that.
>
> > So we consider that add the switch function to the kernel resolves the
> > problem from the source.
> > Then this function will be inherited by Android & Chrome OS.
>
> Don't circumvent horribly governed userspace projects by getting changes
> into the Linux kernel. Go fix those projects instead.
>
> Good luck,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Dear All：
As far as I know, except switching in kernel, there isn't any mode switch solution on Android now.
Do you have any good ideas for the mode switch on Android system?
Best Regards,
Franko Fang
> -----Original Message-----
> From: Dan Williams [mailto:[email protected]]
> Sent: Wednesday, March 06, 2013 11:46 PM
> To: Greg KH
> Cc: Linlei (Lei Lin); Bjørn Mork; [email protected];
> [email protected]; Xueguiying (Zihan); Yili (Neil); Wangyuhua;
> Huqiao (C); [email protected]; [email protected];
> [email protected]; stable; Fangxiaozhi (Franko)
> Subject: Re: 答复: [PATCH] USB: storage: fix Huawei mode switching
> regression
>
> On Wed, 2013-03-06 at 09:44 +0800, Greg KH wrote:
> > On Wed, Mar 06, 2013 at 01:34:44AM +0000, Linlei (Lei Lin) wrote:
> > > Hello Mork,
> > >
> > > >> ------ Because in the embedded linux system, Android, or Chrome
> > > >> OS, etc. They don't integrate userspace usb_modeswitch utility
> > > >> for switching.
> > >
> > > >Why not? If they can upgrade the kernel, then they most certainly can
> install a userspace utility.
> > >
> > > >There is no excuse for an embedded system to do this differently.
> > > >Please see e.g. OpenWRT as an example of an embedded system doing
> this correctly.
> > >
> > > But currently Android and Chrome OS has not integrated the
> > > usb_modeswitch utility.
> >
> > That is not a kernel problem. I find it hard to believe that Chrome
> > OS would not gladly accept code to resolve this issue, can't you put
> > it into the modemmanager or whatever Chrome OS uses to handle their
> > wireless modems?
>
> They use ModemManager, and that's still not the best place to put
> modeswitching. The best place to modeswitch anything is usb_modeswitch.
> No sense duplicating the functionality that usb_modeswitch already supplies.
>
> Dan
>
> >
> > As for Android, sorry, you are on your own, you will just have to deal
> > with the individual OEMs that are incorporating your hardware :(
> >
> > > From a vendor's point of view, our purpose is to make our devices be
> > > supported natively by those OS.
> >
> > We have a solution, usb_modeswitch, any user should be using that.
> >
> > > So we consider that add the switch function to the kernel resolves
> > > the problem from the source.
> > > Then this function will be inherited by Android & Chrome OS.
> >
> > Don't circumvent horribly governed userspace projects by getting
> > changes into the Linux kernel. Go fix those projects instead.
> >
> > Good luck,
> >
> > greg k-h
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to [email protected] More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Thu, Mar 07, 2013 at 02:54:38AM +0000, Fangxiaozhi (Franko) wrote:
> Dear All：
> As far as I know, except switching in kernel, there isn't any mode switch solution on Android now.
> Do you have any good ideas for the mode switch on Android system?
Please discuss this with the Android developers, there's nothing that us
(the kernel community) can do about the Android userspace code, sorry.
Please work with Google to solve this properly there.
good luck,
greg k-h
"Fangxiaozhi (Franko)" <[email protected]> writes:
> As far as I know, except switching in kernel, there isn't any
> mode switch solution on Android now. Do you have any good ideas
> for the mode switch on Android system?
Josh, the usb_modeswitch maintainer, is also maintaining this Android app:
http://www.draisberghof.de/android/pppwidget.html
That's one possible solution. According to him, there is also
"a number of Chinese Android tablets (from the A10 family) that are
supporting a number of 3G modem sticks by providing usb_modeswitch
on-board, which is obviously working well."
That's another possible solution.
Userspace mode switching on Android should not be any more difficult
than userspace mode switching on any other Linux distro. You unbind the
usb-storage driver and submit your bulk message. Looking at a sample
Android device (Galaxy S3 running the default image):
shell@android:/ $ cat /proc/version
Linux version 3.0.31-836582 (se.infra@SEP-97) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT Tue Jan 15 14:17:21 KST 2013
shell@android:/ $ ls -l /dev/bus/usb/001/
crw-rw---- root usb 189, 0 2013-02-19 19:51 001
crw-rw---- root usb 189, 2 2013-03-07 09:01 003
it looks like your app will need to be a member of the "usb" group to do
this. I assume there is a way for an app to request such permissions in
Android. Josh has obviously managed to get it.
Bjørn
Am 07.03.2013 13:19, schrieb Bjørn Mork:
> it looks like your app will need to be a member of the "usb" group to do
> this. I assume there is a way for an app to request such permissions in
> Android. Josh has obviously managed to get it.
Actually, the PPP Widget app requires access to a root shell because it is intended for user installation; however, for a system integrator it should not be hard to add a system app that handles USB devices.
Device discovery is provided by Android since 3.1, permitting device handling in place of an udev system.
A completely different question is if tablet manufacturers are keen on making their Wifi-only devices ready for 3G data via USB devices. It may conflict with their business interests if they are offering 3G-enabled devices for an extra charge.
They may come to the conclusion to patch out the 'huawei_init' feature altogether.
Josua Dietze