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

[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)]

> -----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

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)]

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

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)]

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
> 

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