[PATCH 3.12 21/82] usb-storage: ignore ZTE MF 823 card reader in mode 0x1225

From: Jiri Slaby
Date: Mon Aug 24 2015 - 05:32:21 EST


From: Oliver Neukum <oneukum@xxxxxxxx>

3.12-stable review patch. If anyone has any objections, please let me know.

===============

commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream.

This device automatically switches itself to another mode (0x1405)
unless the specific access pattern of Windows is followed in its
initial mode. That makes a dirty unmount of the internal storage
devices inevitable if they are mounted. So the card reader of
such a device should be ignored, lest an unclean removal become
inevitable.

This replaces an earlier patch that ignored all LUNs of this device.
That patch was overly broad.

Signed-off-by: Oliver Neukum <oneukum@xxxxxxxx>
Reviewed-by: Lars Melin <larsm17@xxxxxxxxx>
Signed-off-by: Jiri Slaby <jslaby@xxxxxxx>
---
drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 00b47646522b..ff273d527b6e 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2045,6 +2045,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0200,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_READ_DISC_INFO ),

+/* Reported by Oliver Neukum <oneukum@xxxxxxxx>
+ * This device morphes spontaneously into another device if the access
+ * pattern of Windows isn't followed. Thus writable media would be dirty
+ * if the initial instance is used. So the device is limited to its
+ * virtual CD.
+ * And yes, the concept that BCD goes up to 9 is not heeded */
+UNUSUAL_DEV( 0x19d2, 0x1225, 0x0000, 0xffff,
+ "ZTE,Incorporated",
+ "ZTE WCDMA Technologies MSM",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_SINGLE_LUN ),
+
/* Reported by Sven Geggus <sven-usbst@xxxxxxxxxx>
* This encrypted pen drive returns bogus data for the initial READ(10).
*/
--
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/