usb-storage: Add support for unusual device by Sierra Wireless
Subsystems (2)
PATCH 1/1 usb-storage: Add support for unusual device by Sierra Wireless
From: Kevin Lloyd <[email protected]>
This patch is targeted for the 2.6.21.1 kernel source. It adds support
for Sierra Wireless devices with auto-install support to the unusual_devices list of the usb-mass storage driver. This requires changes to Kconfig, Makefile, usb.c, unusual_devs.h, and the addition of sierra_ms.h & sierra_ms.c.
---
drivers/usb/storage/Kconfig +0 -0
@@ -105,6 +105,13 @@ config USB_STORAGE_SDDR55
Say Y here to include additional code to support the Sandisk SDDR-55 SmartMedia reader in the USB Mass Storage driver.
+config USB_STORAGE_SIERRA
+ bool "Sierra Wireless Modem Support"
+ depends on USB_STORAGE
+ help
+ Say Y here in order to support new Sierra Wireless devices with the
+ auto install feature.
+ config USB_STORAGE_JUMPSHOT
bool "Lexar Jumpshot Compact Flash Reader (EXPERIMENTAL)" depends on USB_STORAGE && EXPERIMENTAL
drivers/usb/storage/Makefile +0 -0
@@ -21,6 +21,7 @@ usb-storage-obj-$(CONFIG_USB_STORAGE_JUM
usb-storage-obj-$(CONFIG_USB_STORAGE_ALAUDA) += alauda.o
usb-storage-obj-$(CONFIG_USB_STORAGE_ONETOUCH) += onetouch.o
usb-storage-obj-$(CONFIG_USB_STORAGE_KARMA) += karma.o
+usb-storage-obj-$(CONFIG_USB_STORAGE_SIERRA) += sierra_ms.o
usb-storage-objs := scsiglue.o protocol.o transport.o usb.o \ initializers.o $(usb-storage-obj-y)
drivers/usb/storage/sierra_ms.c +82 -0
82 lines not on this page · raw message
drivers/usb/storage/sierra_ms.h +41 -0
41 lines not on this page · raw message
drivers/usb/storage/unusual_devs.h +0 -0
@@ -1361,6 +1361,17 @@ UNUSUAL_DEV( 0x1019, 0x0c55, 0x0000, 0x
US_SC_DEVICE, US_PR_DEVICE, usb_stor_ucr61s2b_init, 0 ),
+/* Reported by Kevin Lloyd <[email protected]>
+ * Entry is needed for the initializer function override, + * which instructs the device to load as a modem
+ * device.
+ */
+UNUSUAL_DEV( 0x1199, 0x0fff, 0x0000, 0x9999,
+ "Sierra Wireless",
+ "USB MMC Storage",
+ US_SC_DEVICE, US_PR_DEVICE, sierra_ms_init, + 0),
+
/* Reported by Jaco Kroon <[email protected]>
* The usb-storage module found on the Digitech GNX4 (and supposedly other
* devices) misbehaves and causes a bunch of invalid I/O errors.
drivers/usb/storage/usb.c +0 -0
@@ -101,6 +101,10 @@
#ifdef CONFIG_USB_STORAGE_KARMA
#include "karma.h"
#endif
+#ifdef CONFIG_USB_STORAGE_SIERRA
+#include "sierra_ms.h"
+#endif
+
/* Some informational data */MODULE_AUTHOR("Matthew Dharm <[email protected]>");
drivers/usb/storage/sierra_ms.c line 49
Quoted 5 lines · Kevin Lloyd
drivers/usb/storage/sierra_ms.c +5
-0+schedule_timeout_uninterruptible (delay_t*HZ ); + retval =sierra_ms_change_mode (us, SWIMS_SET_MODE_Modem); +if (retval == -ETIMEDOUT || retval == -ETIME ) { +US_DEBUGP ("sierra_ms: Command timed out.\n" ); + retries--;
This is strange. The two values should not typically be mixed this way.
ETIMEOUT happens when we (host) sent the setup packet, device took it, and then posted NAKs for all data-in that we did, so eventually (after 5s), we unlinked the URB. This means that the device works, just doesn't want to perform the command in time. The bus itself functions fine.
ETIME means that something has violated the bus protocol. It's like -EBUS for MMIO on PCI. Usually it means that the firmware in the device is completely dead. You can call this a timeout in some sense, but in reality it's no different from EILSEQ. We just report a different code for finer shades of debugging. It happens in less than a millisecond.
I think you just need to test for ETIMEDOUT for that message.
drivers/usb/storage/sierra_ms.c line 78
Quoted 12 lines
drivers/usb/storage/sierra_ms.c +11
-0+int result; +unsigned char *blankArray; + blankArray =kmalloc (0 ,GFP_KERNEL ); + result =usb_stor_control_msg (us, us->send_ctrl_pipe, + SWIMS_USB_REQUEST_SetMode, + SWIMS_USB_REQUEST_TYPE_SetMode, + eSocMode, + SWIMS_USB_INDEX_SetMode, + blankArray, +0 , +5 *HZ );
The blankArray is completely unnecessary here. If something hits a NULL despite the zero transfer size, it has to be fixed.
-- Pete
Quoted 4 lines · Kevin Lloyd
From: Kevin Lloyd <[email protected]>
This patch is targeted for the 2.6.21.1 kernel source. It adds support
for Sierra Wireless devices with auto-install support to theunusual_deviceslist of the usb-mass storage driver. This requires changes toKconfig,Makefile,usb.c,unusual_devs.h, and the addition ofsierra_ms.h&sierra_ms.c.
We have to do a similar thing for some zd1211rw USB-wireless devices, which appear as a virtual CDROM drive on plugin. To convert them to a proper wireless device, the cdrom has to be ejected, then the device disconnects and reconnects with different ID's (and the wireless endpoints).
Originally I wrote a usb-storage subdriver to handle the auto-eject, but this was rejected. It was decided to make usb-storage simply ignore the devices, and have the zd1211rw driver do the eject operation. The same may also apply in your case. See the US_FL_IGNORE_DEVICE flag, and the DEVICE_INSTALLER handling in drivers/net/wireless/zd1211rw/zd_usb.c
Daniel
Not a bad idea. When using the US_FL_IGNORE_DEVICE flag, that causes the usb-storage driver to no load the device and allow another driver properly load it? The reason I ask is because I previously had a separate driver for the device, however there were priority issues regarding which loaded first usb-storage or the separate driver.
Thanks,
- Kevin
-----Original Message-----
From: Daniel Drake [mailto:[email protected]]
Sent: Monday, May 14, 2007 3:59 PM
To: Kevin Lloyd
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH] usb-storage: Add support for unusual device by Sierra Wireless
Quoted 8 lines · Kevin Lloyd
From: Kevin Lloyd <[email protected]>
This patch is targeted for the 2.6.21.1 kernel source. It adds support
for Sierra Wireless devices with auto-install support to the
unusual_deviceslist of the usb-mass storage driver. This requires changes toKconfig,Makefile,usb.c,unusual_devs.h, and the addition ofsierra_ms.h&sierra_ms.c.
We have to do a similar thing for some zd1211rw USB-wireless devices, which appear as a virtual CDROM drive on plugin. To convert them to a proper wireless device, the cdrom has to be ejected, then the device disconnects and reconnects with different ID's (and the wireless endpoints).
Originally I wrote a usb-storage subdriver to handle the auto-eject, but this was rejected. It was decided to make usb-storage simply ignore the devices, and have the zd1211rw driver do the eject operation. The same may also apply in your case. See the US_FL_IGNORE_DEVICE flag, and the DEVICE_INSTALLER handling in drivers/net/wireless/zd1211rw/zd_usb.c
Daniel
Quoted 5 lines · Kevin Lloyd
Not a bad idea. When using the
US_FL_IGNORE_DEVICEflag, that causes the usb-storage driver to no load the device and allow another driver properly load it? The reason I ask is because I previously had a separate driver for the device, however there were priority issues regarding which loaded first usb-storage or the separate driver.
Yes, that's what it's designed for. If usb-storage does come first, the US_FL_IGNORE_DEVICE flag causes it to return -ENODEV from probe, which causes the driver core to look for other candidate drivers to claim the device.
Daniel