summaryrefslogtreecommitdiff
path: root/drivers/usb/storage
AgeCommit message (Collapse)AuthorFilesLines
2016-03-21usb-storage: ignore ZTE MF 823 card reader in mode 0x1225Oliver Neukum1-0/+12
commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream. This device automatically switches itself to another mode (0x1405) unless the specific access pattern of Windows is followed in its initial mode. That makes a dirty unmount of the internal storage devices inevitable if they are mounted. So the card reader of such a device should be ignored, lest an unclean removal become inevitable. This replaces an earlier patch that ignored all LUNs of this device. That patch was overly broad. Signed-off-by: Oliver Neukum <oneukum@suse.com> Reviewed-by: Lars Melin <larsm17@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2015-09-18usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devicesHans de Goede1-0/+7
commit 172115090f5e739660b97694618a2ba86457063a upstream. Without this flag some versions of these enclosures do not work. Reported-and-tested-by: Christian Schaller <cschalle@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2015-04-14usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controllerDmitry Nezhevenko1-0/+7
commit bf5c4136fa5ce471bdbf4cf59a813e32755fd014 upstream. 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: Dmitry Nezhevenko <dion@dion.org.ua> Cc: Phil Dibowitz <phil@ipom.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2015-04-14usb-storage/SCSI: Add broken_fua blacklist flagAlan Stern2-0/+11
commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream. Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Michael Büsch <m@bues.ch> Tested-by: Michael Büsch <m@bues.ch> Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2015-02-02usb-storage: handle a skipped data phaseAlan Stern1-0/+26
commit 93c9bf4d1838d5851a18ca398b0ad66397f05056 upstream. 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 <stern@rowland.harvard.edu> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Tested-by: Paul Osmialowski <newchief@king.net.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: change usb_stor_dbg() to US_DEBUGP()] Signed-off-by: Zefan Li <lizefan@huawei.com>
2014-12-01USB: storage: Add quirks for Entrega/Xircom USB to SCSI convertersMark1-0/+20
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 <markk@clara.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2014-12-01USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapterMark1-0/+6
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 <markk@clara.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2014-12-01USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI AdapterMark1-0/+6
commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream. 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: Mark Knibbs <markk@clara.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2014-12-01storage: Add single-LUN quirk for Jaz USB AdapterMark1-0/+6
commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream. 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: Mark Knibbs <markk@clara.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com>
2014-06-08USB: Nokia 5300 should be treated as unusual devDaniele Forsi1-0/+7
commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-08USB: Nokia 305 should be treated as unusual devVictor A. Santos1-0/+7
commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream. Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-08usb: storage: shuttle_usbat: fix discs being detected twiceDaniele Forsi1-1/+1
commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream. Even if the USB-to-ATAPI converter supported multiple LUNs, this driver would always detect the same physical device or media because it doesn't use srb->device->lun in any way. Tested with an Hewlett-Packard CD-Writer Plus 8200e. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: enable multi-LUN scanning when neededAlan Stern2-1/+9
commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream. People sometimes create their own custom-configured kernels and forget to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug in a USB storage device (such as a card reader) with more than one LUN. Fortunately, we can tell fairly easily when a storage device claims to have more than one LUN. When that happens, this patch asks the SCSI layer to probe all the LUNs automatically, regardless of the config setting. The patch also updates the Kconfig help text for usb-storage, explaining that CONFIG_SCSI_MULTI_LUN may be necessary. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Thomas Raschbacher <lordvan@lordvan.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> CC: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: restrict bcdDevice range for Super Top in Cypress ATACBAlan Stern1-1/+1
commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream. The Cypress ATACB unusual-devs entry for the Super Top SATA bridge causes problems. Although it was originally reported only for bcdDevice = 0x160, its range was much larger. This resulted in a bug report for bcdDevice 0x220, so the range was capped at 0x219. Now Milan reports errors with bcdDevice 0x150. Therefore this patch restricts the range to just 0x160. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22usb-storage: add unusual-devs entry for BlackBerry 9000Alan Stern1-0/+7
commit c5637e5119c43452a00e27c274356b072263ecbb upstream. This patch adds an unusual-devs entry for the BlackBerry 9000. This fixes Bugzilla #22442. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06USB: Nokia 502 is an unusual deviceMikhail Zolotaryov1-0/+7
commit 0e16114f2db4838251fb64f3b550996ad3585890 upstream. The USB storage operation of Nokia Asha 502 Dual SIM smartphone running Asha Platform 1.1.1 is unreliable in respect of data consistency (i.e. transfered files are corrupted). A similar issue is described here: http://discussions.nokia.com/t5/Asha-and-other-Nokia-Series-30/Nokia-301-USB-transfers-and-corrupted-files/td-p/1974170 The workaround is (MAX_SECTORS_64): rmmod usb_storage && modprobe usb_storage quirks=0421:06aa:m The patch adds the tested device to the unusual list permanently. Signed-off-by: Mikhail Zolotaryov <lebon@lebon.org.ua> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04USB: storage: Add MicroVault Flash Drive to unusual_devsRen Bigcren1-0/+7
commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream. The device report an error capacity when read_capacity_16(). Using read_capacity_10() can get the correct capacity. Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-08usb-storage: CY7C68300A chips do not support Cypress ATACBTormod Volden1-2/+14
commit 671b4b2ba9266cbcfe7210a704e9ea487dcaa988 upstream. Many cards based on CY7C68300A/B/C use the USB ID 04b4:6830 but only the B and C variants (EZ-USB AT2LP) support the ATA Command Block functionality, according to the data sheets. The A variant (EZ-USB AT2) locks up if ATACB is attempted, until a typical 30 seconds timeout runs out and a USB reset is performed. https://bugs.launchpad.net/bugs/428469 It seems that one way to spot a CY7C68300A (at least where the card manufacturer left Cypress' EEPROM default vaules, against Cypress' recommendations) is to look at the USB string descriptor indices. A http://media.digikey.com/pdf/Data%20Sheets/Cypress%20PDFs/CY7C68300A.pdf B http://www.farnell.com/datasheets/43456.pdf C http://www.cypress.com/?rID=14189 Note that a CY7C68300B/C chip appears as CY7C68300A if it is running in Backward Compatibility Mode, and if ATACB would be supported in this case there is anyway no way to tell which chip it really is. For 5 years my external USB drive has been locking up for half a minute when plugged in and ata_id is run by udev, or anytime hdparm or similar is run on it. Finally looking at the /correct/ datasheet I think I found the reason. I am aware the quirk in this patch is a bit hacky, but the hardware manufacturers haven't made it easy for us. Signed-off-by: Tormod Volden <debian.tormod@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-28usb-storage: add unusual_devs entry for Samsung YP-Z3 mp3 playerDmitry Artamonow1-0/+7
commit 29f86e66428ee083aec106cca1748dc63d98ce23 upstream. Device stucks on filesystem writes, unless following quirk is passed: echo 04e8:5136:m > /sys/module/usb_storage/parameters/quirks Add corresponding entry to unusual_devs.h Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-03-21USB: storage: fix Huawei mode switching regressionBjørn Mork3-78/+331
commit ab4b71644a26d1ab92b987b2fd30e17c25e89f85 upstream. 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 Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: <fangxiaozhi@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-28USB: usb-storage: unusual_devs update for Super TOP SATA bridgeJosh Boyer1-1/+1
commit 18e03310b5caa6d11c1a8c61b982c37047693fba upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011 Reported-by: Carsten S. <carsteniq@yahoo.com> Tested-by: Carsten S. <carsteniq@yahoo.com> Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-28USB: storage: properly handle the endian issues of idProductfangxiaozhi1-2/+2
commit cd060956c5e97931c3909e4a808508469c0bb9f6 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by: fangxiaozhi <huananhu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-11USB: storage: optimize to match the Huawei USB storage devices and support ↵fangxiaozhi3-331/+78
new switch command commit 200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f upstream. 1. Optimize the match rules with new macro for Huawei USB storage devices, to avoid to load USB storage driver for the modem interface with Huawei devices. 2. Add to support new switch command for new Huawei USB dongles. Signed-off-by: fangxiaozhi <huananhu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-11USB: storage: Define a new macro for USB storage match rulesfangxiaozhi2-0/+27
commit 07c7be3d87e5cdaf5f94c271c516456364ef286c upstream. 1. Define a new macro for USB storage match rules: matching with Vendor ID and interface descriptors. Signed-off-by: fangxiaozhi <huananhu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-17USB: mark uas driver as BROKENGreg Kroah-Hartman1-1/+1
commit fb37ef98015f864d22be223a0e0d93547cd1d4ef upstream. As reported https://bugzilla.kernel.org/show_bug.cgi?id=51031, the UAS driver causes problems and has been asked to be not built into any of the major distributions. To prevent users from running into problems with it, and for distros that were not notified, just mark the whole thing as broken. Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-31usb-storage: add unusual_devs entry for Casio EX-N1 digital cameraMichael Shigorin1-0/+6
commit d7870af7e2e3a91b462075ec1ca669b482215187 upstream. This commit sets removable subclass for Casio EX-N1 digital camera. The patch has been tested within an ALT Linux kernel: http://git.altlinux.org/people/led/packages/?p=kernel-image-3.0.git;a=commitdiff;h=c0fd891836e89fe0c93a4d536a59216d90e4e3e7 See also https://bugzilla.kernel.org/show_bug.cgi?id=49221 Signed-off-by: Oleksandr Chumachenko <ledest@gmail.com> Signed-off-by: Michael Shigorin <mike@osdn.org.ua> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-08-09Revert "usb/uas: make sure data urb is gone if we receive status before that"Gerd Hoffmann1-75/+15
commit c621a81edecdee85da32c566c21836332c764fda upstream. This reverts commit e4d8318a85779b25b880187b1b1c44e797bd7d4b. This patch makes uas.c call usb_unlink_urb on data urbs. The data urbs get freed in the completion callback. This is illegal according to the usb_unlink_urb documentation. This patch also makes the code expect the data completion callback being called before the status completion callback. This isn't guaranteed to be the case, even though the actual data transfer should be finished by the time the status is received. Background: The ehci irq handler for example only know that there are finished transfers, it then has go check the QHs & TDs to see which transfers did actually finish. It has no way to figure in which order the transfers did complete. The xhci driver can call the callbacks in completion order thanks to the event queue. This does nicely explain why the driver is solid on a (usb2) xhci port whereas it goes crazy on ehci in my testing. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16usb-storage: revert commit afff07e61a52 (Add 090c:1000 to unusal-devs)Alan Stern1-7/+0
commit 0070513b5e005161a7a7fd9a3f48f982b41eb094 upstream. This patch (as1560) reverts commit afff07e61a5243e14ee3f0a272a0380cd744a8a3 (usb-storage: Add 090c:1000 to unusal-devs). It is no longer needed, because usb-storage now tells the sd driver to try READ CAPACITY(10) before READ CAPACITY(16) for every USB mass-storage device. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Hans de Goede <hdegoede@redhat.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-16SCSI & usb-storage: add try_rc_10_first flagAlan Stern1-0/+6
commit 6a0bdffa0073857870a4ed1b4489762146359eb4 upstream. Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result. The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2. It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly. Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to. This fixes Bugzilla #43391. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Hans de Goede <hdegoede@redhat.com> CC: "James E.J. Bottomley" <JBottomley@parallels.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-22usb-storage: Add 090c:1000 to unusal-devsHans de Goede1-0/+7
commit afff07e61a5243e14ee3f0a272a0380cd744a8a3 upstream. 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: Hans de Goede <hdegoede@redhat.com> Tested-by: Simon Raffeiner <sturmflut@lieberbiber.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb-storage: unusual_devs entry for Yarvik PMP400 MP4 playerAlan Stern1-0/+7
commit df767b71e5816692134d59c0c17e0f77cd73333d upstream. This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400 MP4 music player. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Jesse Feddema <jdfeddema@gmail.com> Tested-by: Jesse Feddema <jdfeddema@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-07usb: storage: fix lockdep warning inside usb_stor_pre_reset(v2)Ming Lei1-0/+30
This patch fixes one lockdep warning[1] inside usb_stor_pre_reset. If the current configuration includes multiple mass storage interfaces, the 'AA' lockdep warning will be triggered since the lock class of 'us->dev_mutex' is acquired two times in .reset path. It isn't a real deadlock, so just take the lockdep_set_class annotation to remove the warning. [1], lockdep warning log :[ INFO: possible recursive locking detected ] :3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Tainted: G W :--------------------------------------------- :usb-storage/14846 is trying to acquire lock: : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage] :but task is already holding lock: : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage] :other info that might help us debug this: : Possible unsafe locking scenario: : CPU0 : ---- : lock(&(us->dev_mutex)); : lock(&(us->dev_mutex)); : *** DEADLOCK *** : May be due to missing lock nesting notation :2 locks held by usb-storage/14846: : #0: (&__lockdep_no_validate__){......}, at: [<ffffffff8147e6a5>] usb_lock_device_for_reset+0x95/0x100 : #1: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage] :stack backtrace: :Pid: 14846, comm: usb-storage Tainted: G W 3.3.0-0.rc5.git3.1.fc17.x86_64 #1 :Call Trace: : [<ffffffff810cbdaf>] __lock_acquire+0x168f/0x1bb0 : [<ffffffff81021083>] ? native_sched_clock+0x13/0x80 : [<ffffffff810210f9>] ? sched_clock+0x9/0x10 : [<ffffffff810210f9>] ? sched_clock+0x9/0x10 : [<ffffffff810a2975>] ? sched_clock_local+0x25/0xa0 : [<ffffffff810cc9a1>] lock_acquire+0xa1/0x1e0 : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage] : [<ffffffff81699c86>] mutex_lock_nested+0x76/0x3a0 : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage] : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage] : [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage] : [<ffffffff8148184d>] usb_reset_device+0x7d/0x190 : [<ffffffffa048119c>] usb_stor_port_reset+0x7c/0x80 [usb_storage] : [<ffffffffa0481234>] usb_stor_invoke_transport+0x94/0x560 [usb_storage] : [<ffffffff810cd3b2>] ? mark_held_locks+0xb2/0x130 : [<ffffffff8169dbd0>] ? _raw_spin_unlock_irq+0x30/0x50 : [<ffffffffa047fe3e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage] : [<ffffffffa0481ae3>] usb_stor_control_thread+0x173/0x280 [usb_storage] : [<ffffffffa0481970>] ? fill_inquiry_response+0x20/0x20 [usb_storage] : [<ffffffff8108a3f7>] kthread+0xb7/0xc0 : [<ffffffff816a7d34>] kernel_thread_helper+0x4/0x10 : [<ffffffff8169e0f4>] ? retint_restore_args+0x13/0x13 : [<ffffffff8108a340>] ? kthread_worker_fn+0x1a0/0x1a0 : [<ffffffff816a7d30>] ? gs_change+0x13/0x13 Reported-By: Dave Jones <davej@redhat.com> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-31Documentation: remove references to /etc/modprobe.confLucas De Marchi1-1/+1
Usage of /etc/modprobe.conf file was deprecated by module-init-tools and is no longer parsed by new kmod tool. References to this file are replaced in Documentation, comments and Kconfig according to the context. There are also some references to the old /etc/modules.conf from 2.4 kernels that are being removed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-02-28usb/storage: redefine US_BULK_FLAG_IN and use itSebastian Andrzej Siewior3-16/+17
US_BULK_FLAG_IN is defined as 1 and not used. The USB storage spec says that bit 7 of flags within CBW defines the data direction. 1 is DATA-IN (read from device) and 0 is the DATA-OUT. Bit 6 is obselete and bits 0-5 are reserved. This patch redefines the unsued define US_BULK_FLAG_IN from 1 to 1 << 7 aka 0x80 and replaces the obvious users. In a following patch the storage gadget will use it as well. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-28usb/storage: a couple defines from drivers/usb/storage/transport.h to ↵Sebastian Andrzej Siewior1-39/+0
include/linux/usb/storage.h This moves the BOT data structures for CBW and CSW from drivers internal header file to global include able file in include/. The storage gadget is using the same name for CSW but a different for CBW so I fix it up properly. The same goes for the ub driver and keucr driver in staging. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-25USB: ums_realtek: do not use stack memory for DMA in __do_config_autodelinkjwboyer@redhat.com1-1/+7
__do_config_autodelink passes the data variable to the transport function. If the calling functions pass a stack variable, this will eventually trigger a DMA-API debug backtrace for mapping stack memory in the DMA buffer. Fix this by calling kmemdup for the passed data instead. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-23Merge branch 'usb-3.3-rc4' into usb-nextGreg Kroah-Hartman16-143/+274
This is to pull in the xhci changes and the other fixes and device id updates that were done in Linus's tree. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-22usb-storage: fix freezing of the scanning threadAlan Stern2-62/+35
This patch (as1521b) fixes the interaction between usb-storage's scanning thread and the freezer. The current implementation has a race: If the device is unplugged shortly after being plugged in and just as a system sleep begins, the scanning thread may get frozen before the khubd task. Khubd won't be able to freeze until the disconnect processing is complete, and the disconnect processing can't proceed until the scanning thread finishes, so the sleep transition will fail. The implementation in the 3.2 kernel suffers from an additional problem. There the scanning thread calls set_freezable_with_signal(), and the signals sent by the freezer will mess up the thread's I/O delays, which are all interruptible. The solution to both problems is the same: Replace the kernel thread used for scanning with a delayed-work routine on the system freezable work queue. Freezable work queues have the nice property that you can cancel a work item even while the work queue is frozen, and no signals are needed. The 3.2 version of this patch solves the problem in Bugzilla #42730. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Seth Forshee <seth.forshee@canonical.com> CC: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-10Merge tag 'usb-3.3-rc3' into usb-nextGreg Kroah-Hartman1-1/+1
This is done to resolve a merge conflict with: drivers/usb/class/cdc-wdm.c and to better handle future patches for this driver as it is under active development at the moment. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-09usb-storage: reorganize target-specific codeAlan Stern1-14/+15
Now that usb-storage has a target_alloc() routine, this patch (as1508) moves some existing target-specific code out of the slave_alloc() routine to where it really belongs. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-09SCSI & usb-storage: add flags for VPD pages and REPORT LUNSAlan Stern1-10/+16
This patch (as1507) adds a skip_vpd_pages flag to struct scsi_device and a no_report_luns flag to struct scsi_target. The first is used to control whether sd will look at VPD pages for information on block provisioning, limits, and characteristics. The second prevents scsi_report_lun_scan() from issuing a REPORT LUNS command. The patch also modifies usb-storage to set the new flag bits for all USB devices and targets, and to stop adjusting the scsi_level value. Historically we have seen that USB mass-storage devices often don't support VPD pages or REPORT LUNS properly. Until now we have avoided these things by setting the scsi_level to SCSI_2 for all USB devices. But this has the side effect of storing the LUN bits into the second byte of each CDB, and now we have a report of a device which doesn't like that. The best solution is to stop abusing scsi_level and instead have separate flags for VPD pages and REPORT LUNS. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Perry Wagle <wagle@mac.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03usb/uas: make sure data urb is gone if we receive status before thatSebastian Andrzej Siewior1-15/+75
Just run into the following: - new disk arrived in the system - udev couldn't wait to get its hands on to to run ata_id /dev/sda - this sent the cdb 0xa1 to the device. - my UAS-gadget recevied the cdb and had no idea what to do with it. It decided to send a status URB back with sense set to invalid opcode. - the host side received it status and completed the scsi command. - the host sent another scsi with 4kib data buffer - Now I was confused why the data transfer is only 512 bytes instead of 4kib since the host is always allocating the complete transfer in one go. - Finally the system crashed while walking through the sg list. This patch adds three new flags in order to distinguish between DATA URB completed and outstanding. If we receive status before data, we cancel data and let data complete the command. This solves the problem for IN and OUT transfers but does not work for BIDI. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-02-03usb/uas: move UAS structs / defines into a header fileSebastian Andrzej Siewior1-55/+1
The protocol specific structures and defines which are used by UAS are moved into a header files by this patch so it can be accessed by the UAS gadget as well. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-02-03usb/uas: only bind if the hcd supports SGSebastian Andrzej Siewior1-6/+19
The UAS driver requires SG support by the HCD operating the device. This patch stops UAS from operating on a HCD without sg support and prints a message to let him know. The spec says: |For [USB2] backward compatibility, the device shall present [BOT] as |alternate interface zero (primary) and [UAS] as alternate interface one |(secondary). A device which does not need backward compatibility with |[BOT] shall present [UAS] as alternate interface zero. In [USB2] |systems, the [BOT] driver or an associated filter driver may need to |issue a SET INTERFACE request for alternate interface one and then allow |the [UAS] driver to load. If the user used usb_modeswitch to switch to UAS then he can go back to BOT or use a different HCD. In case UAS is the only interface then there is currently no way out. In future usb_sg_wait() should be extended to provide a non-blocking interface so it can work with the UAS driver. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-02-03Merge tag 'uas_for_sarah' of git://linutronix.de/users/bigeasy/linux into ↵Sarah Sharp1-40/+117
for-uas-next Merge UAS bug fixes from Sebastian Andrzej Siewior, including some patches of mine that he signed. UAS fixes for Sarah
2012-01-26USB: Realtek cr: fix autopm scheduling while atomicStanislaw Gruszka1-1/+1
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=784345 Reported-by: Francis Moreau <francis.moro@gmail.com> Reported-and-tested-by: Christian D <chrisudeussen@gmail.com> Reported-and-tested-by: Jimmy Dorff <jdorff@phy.duke.edu> Reported-and-tested-by: collura@ieee.org Cc: stable@vger.kernel.org # 3.2+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25usb: Re-enable usb-storage support dynamic idHuajun Li1-3/+18
Enable usb-storage support dynamic id again by using a fixed id entry that describes a device using the Bulk-Only transport with the Transparent SCSI protocol. Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25usb: Disable dynamic id of USB storage subdriversHuajun Li13-0/+13
Storage subdrivers, like alauda, datafab and others, don't support dynamic id currently, and it needs lots of work but with very little gain to enable the feature, so disable them in the patch. Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-10Merge branch 'usb-next' of ↵Linus Torvalds14-25/+24
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb * 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (232 commits) USB: Add USB-ID for Multiplex RC serial adapter to cp210x.c xhci: Clean up 32-bit build warnings. USB: update documentation for usbmon usb: usb-storage doesn't support dynamic id currently, the patch disables the feature to fix an oops drivers/usb/class/cdc-acm.c: clear dangling pointer drivers/usb/dwc3/dwc3-pci.c: introduce missing kfree drivers/usb/host/isp1760-if.c: introduce missing kfree usb: option: add ZD Incorporated HSPA modem usb: ch9: fix up MaxStreams helper USB: usb-skeleton.c: cleanup open_count USB: usb-skeleton.c: fix open/disconnect race xhci: Properly handle COMP_2ND_BW_ERR USB: remove dead code from suspend/resume path USB: add quirk for another camera drivers: usb: wusbcore: Fix dependency for USB_WUSB xhci: Better debugging for critical host errors. xhci: Be less verbose during URB cancellation. xhci: Remove debugging about ring structure allocation. xhci: Remove debugging about toggling cycle bits. xhci: Remove debugging for individual transfers. ...
2012-01-09Merge branch 'for-linus' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (53 commits) Kconfig: acpi: Fix typo in comment. misc latin1 to utf8 conversions devres: Fix a typo in devm_kfree comment btrfs: free-space-cache.c: remove extra semicolon. fat: Spelling s/obsolate/obsolete/g SCSI, pmcraid: Fix spelling error in a pmcraid_err() call tools/power turbostat: update fields in manpage mac80211: drop spelling fix types.h: fix comment spelling for 'architectures' typo fixes: aera -> area, exntension -> extension devices.txt: Fix typo of 'VMware'. sis900: Fix enum typo 'sis900_rx_bufer_status' decompress_bunzip2: remove invalid vi modeline treewide: Fix comment and string typo 'bufer' hyper-v: Update MAINTAINERS treewide: Fix typos in various parts of the kernel, and fix some comments. clockevents: drop unknown Kconfig symbol GENERIC_CLOCKEVENTS_MIGR gpio: Kconfig: drop unknown symbol 'CS5535_GPIO' leds: Kconfig: Fix typo 'D2NET_V2' sound: Kconfig: drop unknown symbol ARCH_CLPS7500 ... Fix up trivial conflicts in arch/powerpc/platforms/40x/Kconfig (some new kconfig additions, close to removed commented-out old ones)
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 19:11:18 +0300