linux-stable.git/drivers/usb/storage, branch v3.16.6

uas: Add another ASM1051 usb-id to the uas blacklist

2014-10-15T10:05:30+00:00

commit 710f1bf16ab1b1558f099b62c5011c4cbba6a7bb upstream.

As most ASM1051 based devices, this one has unfixable issues with uas too.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Add US_FL_NO_ATA_1X quirk for Seagate (0bc2:ab20) drives

2014-10-15T10:05:30+00:00

commit f9554a6b199360c2f888173fd600e1eb7ff165ef upstream.

https://bbs.archlinux.org/viewtopic.php?pid=1457492

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Add no-report-opcodes quirk

2014-10-15T10:05:30+00:00

commit 734016b00b50a3c6a0e1fc1b7b217e783f5123a1 upstream.

Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that
the JMicron JMS567 also needs it to work properly with uas (usb-storage always
sets it). Since some of the scsi devs were not to keen on the idea to
outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk
for this, and set it for the JMS567.

*) Which has become a non-issue since we've completely blacklisted uas on
the ASM1051 for other reasons

Reported-and-tested-by: Claudio Bizzarri 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

2014-10-15T10:05:30+00:00

commit 593078525c8b234a35a36ff551b8716464e86481 upstream.

And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one
seems to hang upon receiving an ATA_12 or ATA_16 command.

https://bugzilla.kernel.org/show_bug.cgi?id=79511
https://bbs.archlinux.org/viewtopic.php?id=183190

While at it also add missing documentation for the u value for usb-storage
quirks.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check

2014-10-09T19:23:49+00:00

commit a79e5bc53a9519202dfad7d916761601fcbf8db1 upstream.

Reported-by: kbuild test robot 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Disable uas on ASM1051 devices

2014-10-09T19:23:49+00:00

commit a9c54caa456dccba938005f6479892b589975e6a upstream.

There are a large numbers of issues with ASM1051 devices in uas mode:

1) They do not support REPORT SUPPORTED OPERATION CODES

2) They use out of spec 8 byte status iu-s when they have no sense data,
   switching to normal 16 byte status iu-s when they do have sense data.

3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd.

4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks
   with which then normally do work (once 1 & 2 are worked around).

Where as in BOT mode they appear to work fine, so the best way forward with
these devices is to just blacklist them for uas usage.

Unfortunately this is easier said then done. as older versions of the ASM1053
(which works fine) use the same usb-id as the ASM1051.

When connected over USB-3 the 2 can be told apart by the number of streams
they support. So this patch adds some less then pretty code to disable uas for
the ASM1051. When connected over USB-2, simply disable uas alltogether for
devices with the shared usb-id.

Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Log a warning when we cannot use uas because the hcd lacks streams

2014-10-09T19:23:49+00:00

commit 43508be512661c905d0320ee73e0b65ef36d2459 upstream.

So that an user who wants to use uas can see why he is not getting uas.

Also move the check down so that we don't warn if there are other reasons
why uas cannot work.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

uas: Only complain about missing sg if all other checks succeed

2014-10-09T19:23:49+00:00

commit cc4deafc86f75f4e716b37fb4ea3572eb1e49e50 upstream.

Don't complain about controllers without sg support if there are other
reasons why uas cannot be used anyways.

Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters

2014-10-05T20:40:59+00:00

commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream.

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: Mark Knibbs 
Signed-off-by: Greg Kroah-Hartman

USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter

2014-10-05T20:40:59+00:00

commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream.

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: Mark Knibbs 
Signed-off-by: Greg Kroah-Hartman