kernel/linux.git/drivers/usb/storage/transport.c, branch linux-4.16.y

USB: storage: remove invalid URL from drivers

2018-01-23T09:22:34+00:00

The old URL for usb-storage driver help is long gone. So remove it from the comments to not confuse people anymore. Reported-by: Matthew Dharm Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: storage: Remove redundant license text

2017-11-04T10:55:38+00:00

Now that the SPDX tag is in all USB files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: add SPDX identifiers to all remaining files in drivers/usb/

2017-11-04T10:48:02+00:00

It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Signed-off-by: Greg Kroah-Hartman Acked-by: Felipe Balbi Acked-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb-storage: fix bogus hardware error messages for ATA pass-thru devices

2017-09-22T08:08:50+00:00

Ever since commit a621bac3044e ("scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands"), people have been getting bogus error messages for USB disk drives using ATA pass-thru. For example: [ 1344.880193] sd 6:0:0:0: [sdb] Attached SCSI disk [ 1345.069152] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [ 1345.069159] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor] [ 1345.069162] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information [ 1345.069168] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 [ 1345.172252] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [ 1345.172258] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] [descriptor] [ 1345.172261] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense information [ 1345.172266] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00 These messages can be quite annoying, because programs like udisks2 provoke them every 10 minutes or so. Other programs can also have this effect, such as those in smartmontools. I don't fully understand how that commit induced the SCSI core to log these error messages, but the underlying cause for them is code added to usb-storage by commit f1a0743bc0e7 ("USB: storage: When a device returns no sense data, call it a Hardware Error"). At the time it was necessary to do this, in order to prevent an infinite retry loop with some not-so-great mass storage devices. However, the ATA pass-thru protocol uses SCSI sense data to return command status values, and some devices always report Check Condition status for ATA pass-thru commands to ensure that the host retrieves the sense data, even if the command succeeded. This violates the USB mass-storage protocol (Check Condition status is supposed to mean the command failed), but we can't help that. This patch attempts to mitigate the problem of these bogus error reports by changing usb-storage. The HARDWARE ERROR sense key will be inserted only for commands that aren't ATA pass-thru. Thanks to Ewan Milne for pointing out that this mechanism was present in usb-storage. 8 years after writing it, I had completely forgotten its existence. Signed-off-by: Alan Stern Tested-by: Kris Lindgren Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1351305 CC: Ewan D. Milne CC: Signed-off-by: Greg Kroah-Hartman

Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y

2016-11-15T10:08:51+00:00

Some code (all error handling) submits CDBs that are allocated on the stack. This breaks with CB/CBI code that tries to create URB directly from SCSI command buffer - which happens to be in vmalloced memory with vmalloced kernel stacks. Let's make copy of the command in usb_stor_CB_transport. Signed-off-by: Petr Vandrovec Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: storage: fix multi-line comment style

2016-04-26T22:04:38+00:00

No functional changes here, just making sure our storage driver uses a consistent multi-line comment style. Signed-off-by: Felipe Balbi Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: usleep_range is preferred over udelay where wakeup is flexible

2015-07-22T22:45:04+00:00

According to Documentation/timers/timers-howto.txt" udelay() is only called once from a place where sleeping is allowed. We can replace it with a call to usleep_range() with a reasonable upper limit. Signed-off-by: Sunny Kumar Signed-off-by: Greg Kroah-Hartman

Merge 3.18-rc4 into usb-next.

2014-11-10T03:10:24+00:00

This resolves a conflict in drivers/usb/host/Kconfig Signed-off-by: Greg Kroah-Hartman

USB: storage: Reject bogus max LUN values

2014-11-07T16:56:05+00:00

Some mass storage devices return a bogus value in response to a Get Max LUN request. The Iomega Jaz USB Adapter responds with 0x10, hence my recent patch to use the US_FL_SINGLE_LUN quirk for it. The USB MSC Bulk Only Transport document says "The device shall return one byte of data that contains the maximum LUN supported by the device." Since the LUN field in the command block wrapper is only 4 bits wide, it might be helpful to report too-large LUN values in the kernel log, and assume max LUN is actually 0. That could get some devices which currently need the US_FL_SINGLE_LUN quirk to work. Signed-off-by: Mark Knibbs Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb-storage: handle a skipped data phase

2014-11-03T23:26:15+00:00

Sometimes mass-storage devices using the Bulk-only transport will mistakenly skip the data phase of a command. Rather than sending the data expected by the host or sending a zero-length packet, they go directly to the status phase and send the CSW. This causes problems for usb-storage, for obvious reasons. The driver will interpret the CSW as a short data transfer and will wait to receive a CSW. The device won't have anything left to send, so the command eventually times out. The SCSI layer doesn't retry commands after they time out (this is a relatively recent change). Therefore we should do our best to detect a skipped data phase and handle it promptly. This patch adds code to do that. If usb-storage receives a short 13-byte data transfer from the device, and if the first four bytes of the data match the CSW signature, the driver will set the residue to the full transfer length and interpret the data as a CSW. This fixes Bugzilla #86611. Signed-off-by: Alan Stern CC: Matthew Dharm Tested-by: Paul Osmialowski CC: Signed-off-by: Greg Kroah-Hartman