1. 09 12月, 2017 1 次提交
  2. 04 11月, 2017 2 次提交
  3. 22 9月, 2017 1 次提交
  4. 26 4月, 2017 1 次提交
  5. 18 4月, 2017 1 次提交
  6. 09 3月, 2017 1 次提交
  7. 06 1月, 2017 1 次提交
  8. 13 9月, 2016 1 次提交
  9. 27 4月, 2016 1 次提交
  10. 02 12月, 2015 1 次提交
  11. 23 7月, 2015 2 次提交
  12. 10 5月, 2015 1 次提交
  13. 25 1月, 2015 2 次提交
    • D
      usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller · bf5c4136
      Dmitry Nezhevenko 提交于
      It looks like FUA support is broken on JMicron 152d:2566 bridge:
      
      [223159.885704] sd 7:0:0:0: [sdc] Write Protect is off
      [223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08
      [223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
      
      [223283.691677] sd 7:0:0:0: [sdc]
      [223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
      [223283.691681] sd 7:0:0:0: [sdc]
      [223283.691682] Sense Key : Illegal Request [current]
      [223283.691684] sd 7:0:0:0: [sdc]
      [223283.691685] Add. Sense: Invalid field in cdb
      [223283.691686] sd 7:0:0:0: [sdc] CDB:
      [223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00
      [223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584
      
      This patch adds blacklist flag so that sd will not use FUA
      Signed-off-by: NDmitry Nezhevenko <dion@dion.org.ua>
      Cc: Phil Dibowitz <phil@ipom.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf5c4136
    • M
      storage: Revise/fix quirk for 04E6:000F SCM USB-SCSI converter · a7a34d02
      Mark Knibbs 提交于
      I recently posted a patch ("storage: Add quirk for another SCM-based
      USB-SCSI converter") to add a quirk for the converter with ID 04E6:000F,
      which is listed along with 04E6:000B in the Windows INF file for the
      Startech ICUSBSCSI2 as "eUSB SCSI Adapter (Bus Powered)".
      
      The already-present quirk for 04E6:000B has USB_SC_SCSI/USB_PR_BULK, not
      USB_SC_DEVICE/USB_PR_DEVICE. Change the 04E6:000F quirk to match that,
      since it will probably be required.
      Signed-off-by: NMark Knibbs <markk@clara.co.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7a34d02
  14. 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
  15. 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
  16. 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
  17. 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
  18. 01 7月, 2014 1 次提交
  19. 04 5月, 2014 2 次提交
  20. 05 3月, 2014 1 次提交
  21. 05 2月, 2014 1 次提交
  22. 04 1月, 2014 1 次提交
  23. 17 10月, 2013 1 次提交
  24. 23 7月, 2013 1 次提交
  25. 16 3月, 2013 1 次提交
  26. 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
  27. 05 2月, 2013 1 次提交
  28. 25 10月, 2012 1 次提交
  29. 06 9月, 2012 1 次提交
  30. 20 7月, 2012 1 次提交
  31. 17 7月, 2012 1 次提交
  32. 23 6月, 2012 1 次提交