1. 24 9月, 2014 2 次提交
    • M
      storage: Add quirk for another SCM-based USB-SCSI converter · 3512e7bf
      Mark Knibbs 提交于
      There is apparently another SCM USB-SCSI converter with ID 04E6:000F. It
      is listed along with 04E6:000B in the Windows INF file for the Startech
      ICUSBSCSI2 as "eUSB SCSI Adapter (Bus Powered)". The quirk allows
      devices with SCSI ID other than 0 to be accessed.
      
      Also make a couple of existing SCM product IDs lower case to be
      consistent with other entries.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3512e7bf
    • M
      storage: Add quirks for Castlewood and Double-H USB-SCSI converters · 57cde01a
      Mark Knibbs 提交于
      Castlewood Systems supplied various models of USB-SCSI converter with their
      ORB external removable-media drive. The ORB Windows and Macintosh drivers
      support six USB IDs:
       084B:A001     [VID 084B is Castlewood Systems]
       04E6:0002 (*) ORB USB Smart Cable P/N 88205-001 (generic SCM ID)
       2027:A001     Double-H Technology DH-2000SC
       1822:0001 (*) Ariston iConnect/iSCSI
       07AF:0004 (*) Microtech XpressSCSI (25-pin)
       07AF:0005 (*) Microtech XpressSCSI (50-pin)
      
      *: quirk already in unusual-devs.h
      
      [Apparently the official VID for Double-H Technology is 0x07EB = 2027
      decimal. That's another hex/decimal mix-up with these SCM-based products
      (in addition to the Ariston and Entrega ones). Perhaps the USB-IF informed
      companies of their allocated VID in decimal, but they assumed it was hex?
      It seems all Entrega products used VID 0x1645, not just the USB-SCSI
      converter.]
      
      Double-H Technology Co., Ltd. produced a USB-SCSI converter, model
      DH-2000SC, which is probably the one supported by the ORB drivers. Perhaps
      the Castlewood-bundled product had a different label or PID though?
      Castlewood mentioned Conmate as being one type of USB-SCSI converter.
      Conmate and Double-H seem related somehow; both company addresses in the
      same road, and at one point the Conmate web site mentioned DH-2000H4,
      DH-200D4/DH-2000C4 as models of USB hub (DH short for Double-H presumably).
      Conmate did show a USB-SCSI converter model CM-660 on their web site at one
      point. My guess is that was identical to the DH-2000SC.
      
      Mention of the Double-H product:
        http://web.archive.org/web/20010221010141/http://www.doubleh.com.tw/dh-2000sc.htm
      The only picture I could find is at
        http://jp.acesuppliers.com/catalog/j64/component/page03.html
      The casing design looks the same as my ORB USB Smart Cable which has ID
      04E6:0002.
      
      Anyway, that's enough rambling. Here's the patch.
      
      storage: Add quirks for Castlewood and Double-H USB-SCSI converters
      
      Add quirks for two SCM-based USB-SCSI converters which were bundled with
      some Castlewood ORB removable drives. Without the quirk only the (single)
      drive with SCSI ID 0 can be accessed.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57cde01a
  2. 20 9月, 2014 3 次提交
    • M
      USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters · c80b4495
      Mark 提交于
      This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB-
      SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The
      US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI
      chain to be accessed. Without it only the (single) device with SCSI ID 0
      can be used.
      
      The standalone converter sold by Entrega had model number U1-SC25. Xircom
      acquired Entrega and re-branded the product line PortGear. The PortGear USB
      to SCSI Converter (model PGSCSI) is internally identical to the Entrega
      product, but later models may use a different USB ID. The Entrega-branded
      units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and
      Macintosh drivers also support 085A:0028.
      
      Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac
      (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as
      a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may
      have initially used the same ID as the standalone U1-SC25 (1645:0007), but
      later production used 085A:0026.
      
      My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133
      probably also exist.
      
      This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows
      driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I
      couldn't find any mention of that actually existing in the wild; perhaps it
      was cancelled before release?
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c80b4495
    • M
      USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter · b6a3ed67
      Mark 提交于
      Hi,
      
      The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g.
      iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM
      Microsystems chips. Only the connectors differ; both have the same USB ID.
      The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other
      than 0.
      
      I don't have one of these, but based on the other entries for Shuttle/
      SCM-based converters this patch is very likely correct. I used 0x0000 and
      0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
      bcdDevice value the products use.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6a3ed67
    • M
      USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter · 67d365a5
      Mark 提交于
      The Adaptec USBConnect 2000 is another SCSI-USB converter which uses
      Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is
      required to use SCSI devices with ID other than 0.
      
      I don't have a USBConnect 2000, but based on the other entries for Shuttle/
      SCM-based converters this patch is very likely correct. I used 0x0000 and
      0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which
      bcdDevice value the product uses.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67d365a5
  3. 12 9月, 2014 1 次提交
    • M
      storage: Add single-LUN quirk for Jaz USB Adapter · c66f1c62
      Mark 提交于
      The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware
      seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/
      SCM chip set. However its firmware restricts it to only work with Jaz
      drives.
      
      On connecting the cable a message like this appears four times in the log:
       reset full speed USB device number 4 using uhci_hcd
      
      That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c66f1c62
  4. 26 8月, 2014 1 次提交
    • M
      USB: storage: add quirk for Newer Technology uSCSI SCSI-USB converter · a7e69ddb
      Mark 提交于
      The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003.
      Like several other SCSI-USB products, it's a Shuttle Technology OEM device.
      Without a suitable entry in unusual-devs.h, the converter can only access the
      (single) device with SCSI ID 0. Copying the entry for device 04e6:0002 allows
      it to work with devices with other SCSI IDs too.
      
      There are currently six entries for Shuttle-developed SCSI-USB devices in
      unusual-devs.h (grep for euscsi):
        04e6:0002  Shuttle eUSCSI Bridge    USB_SC_DEVICE, USB_PR_DEVICE
        04e6:000b  Shuttle eUSCSI Bridge    USB_SC_SCSI, USB_PR_BULK
        04e6:000c  Shuttle eUSCSI Bridge    USB_SC_SCSI, USB_PR_BULK
        050d:0115  Belkin USB SCSI Adaptor  USB_SC_SCSI, USB_PR_BULK
        07af:0004  Microtech USB-SCSI-DB25  USB_SC_DEVICE, USB_PR_DEVICE
        07af:0005  Microtech USB-SCSI-HD50  USB_SC_DEVICE, USB_PR_DEVICE
      
      lsusb -v output for the uSCSI lists
        bInterfaceSubClass      6 SCSI
        bInterfaceProtocol     80 Bulk (Zip)
      
      This patch adds an entry for the uSCSI to unusual_devs.h.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7e69ddb
  5. 01 7月, 2014 1 次提交
  6. 04 5月, 2014 2 次提交
  7. 05 3月, 2014 1 次提交
  8. 05 2月, 2014 1 次提交
  9. 04 1月, 2014 1 次提交
  10. 17 10月, 2013 1 次提交
  11. 23 7月, 2013 1 次提交
  12. 16 3月, 2013 1 次提交
  13. 07 3月, 2013 2 次提交
    • B
      USB: storage: fix Huawei mode switching regression · ab4b7164
      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: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab4b7164
    • B
  14. 05 2月, 2013 1 次提交
  15. 25 10月, 2012 1 次提交
  16. 06 9月, 2012 1 次提交
  17. 20 7月, 2012 1 次提交
  18. 17 7月, 2012 1 次提交
  19. 23 6月, 2012 1 次提交
  20. 14 6月, 2012 1 次提交
    • H
      usb-storage: Add 090c:1000 to unusal-devs · afff07e6
      Hans de Goede 提交于
      This device gives a bogus answer to get_capacity(16):
      [ 8628.278614] scsi 8:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [ 8628.279452] sd 8:0:0:0: Attached scsi generic sg4 type 0
      [ 8628.280338] sd 8:0:0:0: [sdd] 35747322042253313 512-byte logical blocks: (18.3 EB/15.8 EiB)
      
      So set the quirk flag to avoid using get_capacity(16) with it:
      [11731.386014] usb-storage 2-1.6:1.0: Quirks match for vid 090c pid 1000: 80000
      [11731.386075] scsi9 : usb-storage 2-1.6:1.0
      [11731.386172] usbcore: registered new interface driver usb-storage
      [11731.386175] USB Mass Storage support registered.
      [11732.387394] scsi 9:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [11732.388462] sd 9:0:0:0: Attached scsi generic sg3 type 0
      [11732.389432] sd 9:0:0:0: [sdc] 7975296 512-byte logical blocks: (4.08 GB/3.80 GiB)
      
      Which makes the capacity look a lot more sane :)
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Tested-by: NSimon Raffeiner <sturmflut@lieberbiber.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afff07e6
  21. 10 5月, 2012 1 次提交
  22. 28 3月, 2012 1 次提交
  23. 02 1月, 2012 1 次提交
  24. 27 11月, 2011 1 次提交
  25. 09 8月, 2011 1 次提交
  26. 08 6月, 2011 1 次提交
    • A
      usb-storage: redo incorrect reads · 21c13a4f
      Alan Stern 提交于
      Some USB mass-storage devices have bugs that cause them not to handle
      the first READ(10) command they receive correctly.  The Corsair
      Padlock v2 returns completely bogus data for its first read (possibly
      it returns the data in encrypted form even though the device is
      supposed to be unlocked).  The Feiya SD/SDHC card reader fails to
      complete the first READ(10) command after it is plugged in or after a
      new card is inserted, returning a status code that indicates it thinks
      the command was invalid, which prevents the kernel from retrying the
      read.
      
      Since the first read of a new device or a new medium is for the
      partition sector, the kernel is unable to retrieve the device's
      partition table.  Users have to manually issue an "hdparm -z" or
      "blockdev --rereadpt" command before they can access the device.
      
      This patch (as1470) works around the problem.  It adds a new quirk
      flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
      always be retried immediately, as should any failing READ(10) commands
      (provided the preceding READ(10) command succeeded, to avoid getting
      stuck in a loop).  The patch also adds appropriate unusual_devs
      entries containing the new flag.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSven Geggus <sven-usbst@geggus.net>
      Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      21c13a4f
  27. 04 2月, 2011 2 次提交
  28. 23 1月, 2011 2 次提交
  29. 17 12月, 2010 1 次提交
  30. 23 10月, 2010 3 次提交
  31. 21 5月, 2010 1 次提交