[PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command

[PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command

[fangxiaozhi 00110321]

From: fangxiaozhi <huananhu@huawei.com>

1. Optimize the match rules with new macro for Huawei USB storage devices, 
   to avoid to load USB storage driver for the modem interface 
   with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.

Signed-off-by: fangxiaozhi <huananhu@huawei.com>
--------------------------------------------------------------------

diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.c linux-3.8-rc6/drivers/usb/storage/initializers.c
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.c	2013-02-04 14:38:34.268154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.c	2013-02-04 14:52:19.947201855 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
 	return 0;
 }
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
 {
 	int result;
 
@@ -104,3 +104,75 @@ int usb_stor_huawei_e220_init(struct 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 = 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 (us->pusb_dev->descriptor.idProduct >= 0x1446)
+			result = usb_stor_huawei_scsi_init(us);
+		else
+			result = usb_stor_huawei_feature_init(us);
+	}
+	return result;
+}
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/initializers.h linux-3.8-rc6/drivers/usb/storage/initializers.h
--- linux-3.8-rc6_orig/drivers/usb/storage/initializers.h	2013-02-04 14:38:34.269154217 +0800
+++ linux-3.8-rc6/drivers/usb/storage/initializers.h	2013-02-04 14:52:19.947201855 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
  * flash reader */
 int usb_stor_ucr61s2b_init(struct us_data *us);
 
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.8-rc6_orig/drivers/usb/storage/unusual_devs.h linux-3.8-rc6/drivers/usb/storage/unusual_devs.h
--- linux-3.8-rc6_orig/drivers/usb/storage/unusual_devs.h	2013-02-04 14:38:34.267154216 +0800
+++ linux-3.8-rc6/drivers/usb/storage/unusual_devs.h	2013-02-04 14:52:19.949201855 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV(  0x1210, 0x0003, 0x0100, 0x
 /* Reported by fangxiaozhi <huananhu@huawei.com>
  * This brings the HUAWEI data card devices into multi-port mode
  */
-UNUSUAL_DEV(  0x12d1, 0x1001, 0x0000, 0x0000,
+UNUSUAL_VENDOR_INTF(0x12d1, 0x08, 0x06, 0x50,
 		"HUAWEI MOBILE",
 		"Mass Storage",
-		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,
+		USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_init,
 		0),
 
 /* Reported by Vilius Bilinkevicius <vilisas AT xxx DOT lt) */

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)

[Bjørn Mork]

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

[PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

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: <fangxiaozhi@huawei.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
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 <huananhu@huawei.com>
  * 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

Ben Hutchings <ben@decadent.org.uk> 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Matthew Dharm]

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 <bjorn@mork.no> wrote:
> Ben Hutchings <ben@decadent.org.uk> 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

Matthew Dharm <mdharm-usb@one-eyed-alien.net> 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 <bjorn@mork.no> wrote:
>> Ben Hutchings <ben@decadent.org.uk> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Josua Dietze]

Am 04.03.2013 20:22, schrieb Bjørn Mork:
> Matthew Dharm <mdharm-usb@one-eyed-alien.net> 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Oliver Neukum]

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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

Oliver Neukum <oneukum@suse.de> 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

RE: [PATCH] USB: storage: fix Huawei mode switching regression

[Fangxiaozhi (Franko)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 19346 bytes --]



> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Monday, March 04, 2013 9:19 PM
> To: linux-usb@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Fangxiaozhi (Franko); Xueguiying (Zihan);
> Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
> balbi@ti.com; mdharm-usb@one-eyed-alien.net; sebastian@breakpoint.cc;
> 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: <fangxiaozhi@huawei.com>
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> 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 <huananhu@huawei.com>
>   * 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

"Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Oliver Neukum]

On Tuesday 05 March 2013 11:07:05 Bjørn Mork wrote:
> "Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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

Re: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

Oliver Neukum <oneukum@suse.de> writes:
> On Tuesday 05 March 2013 11:07:05 Bjørn Mork wrote:
>> "Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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

答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Linlei (Lei Lin)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 11369 bytes --]

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:bjorn@mork.no] 
发送时间: 2013年3月5日 18:07
收件人: Fangxiaozhi (Franko)
抄送: linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); balbi@ti.com; mdharm-usb@one-eyed-alien.net; sebastian@breakpoint.cc; stable
主题: Re: [PATCH] USB: storage: fix Huawei mode switching regression

"Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Greg KH]

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

Re: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Dan Williams]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Fangxiaozhi (Franko)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2928 bytes --]

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:dcbw@redhat.com]
> Sent: Wednesday, March 06, 2013 11:46 PM
> To: Greg KH
> Cc: Linlei (Lei Lin); Bjørn Mork; linux-usb@vger.kernel.org;
> linux-kernel@vger.kernel.org; Xueguiying (Zihan); Yili (Neil); Wangyuhua;
> Huqiao (C); balbi@ti.com; mdharm-usb@one-eyed-alien.net;
> sebastian@breakpoint.cc; 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 majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Greg KH]

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

Re: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Bjørn Mork]

"Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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

Re: 答复: [PATCH] USB: storage: fix Huawei mode switching regression

[Josua Dietze]

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

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)

[Fangxiaozhi (Franko)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4513 bytes --]

Dear Mork:

	Thank you very much for your test.

> -----Original Message-----
> From: Bjørn Mork [mailto:bjorn@mork.no]
> Sent: Monday, March 04, 2013 7:41 PM
> To: Fangxiaozhi (Franko)
> Cc: linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; Xueguiying
> (Zihan); Linlei (Lei Lin); greg@kroah.com; Yili (Neil); Wangyuhua (Roger, Credit);
> Huqiao (C); balbi@ti.com; mdharm-usb@one-eyed-alien.net;
> sebastian@breakpoint.cc
> 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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)

[Oliver Neukum]

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

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)

[Fangxiaozhi (Franko)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2663 bytes --]

Dear Oliver:

> -----Original Message-----
> From: Oliver Neukum [mailto:oneukum@suse.de]
> Sent: Tuesday, March 05, 2013 4:49 PM
> To: Fangxiaozhi (Franko)
> Cc: Bjørn Mork; linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org;
> Xueguiying (Zihan); Linlei (Lei Lin); greg@kroah.com; Yili (Neil); Wangyuhua
> (Roger, Credit); Huqiao (C); balbi@ti.com; mdharm-usb@one-eyed-alien.net;
> sebastian@breakpoint.cc
> 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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)

[Bjørn Mork]

"Fangxiaozhi (Franko)" <fangxiaozhi@huawei.com> 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

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)

[greg]

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