linux-toradex.git/drivers/usb/storage, branch v2.6.31.12 Linux kernel for Apalis and Colibri modules USB: usb-storage: add BAD_SENSE flag 2009-12-18T21:43:35+00:00 Alan Stern stern@rowland.harvard.edu 2009-12-07T21:39:16+00:00 2e8ca1b618a6df647e0557317a8c0fc7f17c5988 commit a0bb108112a872c0b0c4b3ef4974f95fb75b155d upstream. This patch (as1311) fixes a problem in usb-storage: Some devices are pretty broken when it comes to reporting sense data. The information they send back indicates that they have more than 18 bytes of sense data available, but when the system asks for more than 18 they fail or hang. The symptom is that probing fails with multiple resets. The patch adds a new BAD_SENSE flag to indicate that usb-storage should never ask for more than 18 bytes of sense data. The flag can be set in an unusual_devs entry or via the "quirks=" module parameter, and it is set automatically whenever a REQUEST SENSE command for more than 18 bytes fails or times out. An unusual_devs entry is added for the Agfa photo frame, which uses a Prolific chip having this bug. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Daniel Kukula <daniel.kuku@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit a0bb108112a872c0b0c4b3ef4974f95fb75b155d upstream.

This patch (as1311) fixes a problem in usb-storage: Some devices are
pretty broken when it comes to reporting sense data.  The information
they send back indicates that they have more than 18 bytes of sense
data available, but when the system asks for more than 18 they fail or
hang.  The symptom is that probing fails with multiple resets.

The patch adds a new BAD_SENSE flag to indicate that usb-storage
should never ask for more than 18 bytes of sense data.  The flag can
be set in an unusual_devs entry or via the "quirks=" module parameter,
and it is set automatically whenever a REQUEST SENSE command for more
than 18 bytes fails or times out.

An unusual_devs entry is added for the Agfa photo frame, which uses a
Prolific chip having this bug.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Daniel Kukula <daniel.kuku@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: usb-storage: fix bug in fill_inquiry 2009-12-18T21:43:12+00:00 Alan Stern stern@rowland.harvard.edu 2009-12-07T21:47:43+00:00 9b6950a5e8986e97dd195070443f866035dfc5ef commit f3f6faa9edf67c1018270793e0547b0f81abb47e upstream. This patch (as1312) fixes a minor bug in usb-storage. The fill_inquiry() routine neglects to pre-load the inquiry data buffer with spaces. As a result, if the vendor name is shorter than 8 characters or the product name is shorter than 16, the remainder will be filled with garbage. The patch also removes some unnecessary calls to strlen(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit f3f6faa9edf67c1018270793e0547b0f81abb47e upstream.

This patch (as1312) fixes a minor bug in usb-storage.  The
fill_inquiry() routine neglects to pre-load the inquiry data buffer
with spaces.  As a result, if the vendor name is shorter than 8
characters or the product name is shorter than 16, the remainder will
be filled with garbage.

The patch also removes some unnecessary calls to strlen().

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb-storage: Workaround devices with bogus sense size 2009-10-22T22:12:00+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2009-10-13T04:53:47+00:00 670add0a279e39e13a66876389c64d4f7dcf0379 commit b8430e1b82b7e514d76a88eb70a7d8831d50df1e upstream. usb-storage: Workaround devices with bogus sense size Some devices, such as Huawei E169, advertise more than the standard amount of sense data, causing us to set US_FL_SANE_SENSE, assuming they support it. However, they subsequently fail the request sense with that size. This works around it generically. When a sense request fails due to a device returning an error, US_FL_SANE_SENSE was set, and that sense request used a larger sense size, we retry with a smaller size before giving up. Based on an original patch by Ben Efros <ben@pc-doctor.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit b8430e1b82b7e514d76a88eb70a7d8831d50df1e upstream.

usb-storage: Workaround devices with bogus sense size

Some devices, such as Huawei E169, advertise more than the standard
amount of sense data, causing us to set US_FL_SANE_SENSE, assuming
they support it. However, they subsequently fail the request sense
with that size.

This works around it generically. When a sense request fails due to
a device returning an error, US_FL_SANE_SENSE was set, and that sense
request used a larger sense size, we retry with a smaller size before
giving up.

Based on an original patch by Ben Efros <ben@pc-doctor.com>

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: storage: When a device returns no sense data, call it a Hardware Error 2009-10-22T22:11:50+00:00 Alan Stern stern@rowland.harvard.edu 2009-10-06T18:07:57+00:00 4e45dde88210d0f4300675470b666979de88e965 commit f1a0743bc0e7a30c032b1eb78f6a2b0f805b4597 upstream. This patch (as1294) fixes a problem that has plagued users for several kernel releases. Some USB mass-storage devices don't return any sense data when they encounter certain kinds of errors. The SCSI layer interprets this to mean that the operation should be retried, and the same thing happens -- over and over again with no limit. In some circumstances (such as when a bus reset occurs) that is the right thing to do, but not here. The patch checks for this condition (a transport failure with no sense data) and changes the result code to DID_ERROR and the sense code to Hardware Error. This does get only a limited number of retries, and so the command will fail relatively quickly instead of getting stuck in an infinite loop. This fixes a large part of Bugzilla #14118. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Mantas Mikulenas <grawity@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit f1a0743bc0e7a30c032b1eb78f6a2b0f805b4597 upstream.

This patch (as1294) fixes a problem that has plagued users for several
kernel releases.  Some USB mass-storage devices don't return any sense
data when they encounter certain kinds of errors.  The SCSI layer
interprets this to mean that the operation should be retried, and the
same thing happens -- over and over again with no limit.  In some
circumstances (such as when a bus reset occurs) that is the right
thing to do, but not here.

The patch checks for this condition (a transport failure with no sense
data) and changes the result code to DID_ERROR and the sense code to
Hardware Error.  This does get only a limited number of retries, and
so the command will fail relatively quickly instead of getting stuck
in an infinite loop.

This fixes a large part of Bugzilla #14118.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Mantas Mikulenas <grawity@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: usb-storage fails to attach to Huawei Datacard cdrom device 2009-10-05T16:32:01+00:00 fangxiaozhi huananhu@huawei.com 2009-08-07T04:30:35+00:00 b7c8b54df8c2a82757d8aab48aaac198a49e2ff9 commit d0defb855c8504c49b92bdc0203689ce9b4cf7ba upstream. In this patch, we always make the return value of function usb_stor_huawei_e220_init to be zero. Then it will not prevent usb-storage driver from attaching to the CDROM device of Huawei Datacard. Signed-off-by: fangxiaozhi <huananhu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit d0defb855c8504c49b92bdc0203689ce9b4cf7ba upstream.

In this patch, we always make the return value of function
usb_stor_huawei_e220_init to be zero. Then it will not prevent usb-storage
driver from attaching to the CDROM device of Huawei Datacard.

Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: storage: fix a resume path GFP_NOIO must be used 2009-10-05T16:32:01+00:00 Oliver Neukum oliver@neukum.org 2009-08-26T17:56:12+00:00 68eeb516062536e6877a5e0dc890235157dfe745 commit e5dc8ae121592239c2a2521d383bcb789849b2a3 upstream. In the resume path of a block driver GFP_NOIO must be used to avoid a possible deadlock. The onetouch subdriver of storage violates the requirement. Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e5dc8ae121592239c2a2521d383bcb789849b2a3 upstream.

In the resume path of a block driver GFP_NOIO must be used to
avoid a possible deadlock. The onetouch subdriver of storage violates
the requirement.

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: storage: include Prolific Technology USB drive in unusual_devs list 2009-08-07T23:05:14+00:00 Rogerio Brito rbrito@ime.usp.br 2009-08-06T22:20:19+00:00 c15e3ca1d822abba78c00b1ffc3e7b382a50396e Add a quirk entry for the Leading Driver UD-11 usb flash drive. As Alan Stern told me, the device doesn't deal correctly with the locking media feature of the device, and this patch incorporates it. Compiled, tested, working. Signed-off-by: Rogerio Brito <rbrito@ime.usp.br> Cc: Phil Dibowitz <phil@ipom.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Robert Hancock <hancockrwd@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Add a quirk entry for the Leading Driver UD-11 usb flash drive.

As Alan Stern told me, the device doesn't deal correctly with the
locking media feature of the device, and this patch incorporates it.

Compiled, tested, working.

Signed-off-by: Rogerio Brito <rbrito@ime.usp.br>
Cc: Phil Dibowitz <phil@ipom.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Robert Hancock <hancockrwd@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: storage: raise timeout in usb_stor_Bulk_max_lun 2009-07-28T21:31:09+00:00 Giacomo Lozito james@develia.org 2009-07-13T21:23:33+00:00 7a777919bbeec3eac1d7904a728a60e9c2bb9c67 Requests to get max LUN, for certain USB storage devices, require a longer timeout before a correct reply is returned. This happens for a Realtek USB Card Reader (0bda:0152), which has a max LUN of 3 but is set to 0, thus losing functionality, because of the timeout occurring too quickly. Raising the timeout value fixes the issue and might help other devices to return a correct max LUN value as well. Signed-off-by: Giacomo Lozito <james@develia.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Requests to get max LUN, for certain USB storage devices, require a
longer timeout before a correct reply is returned. This happens for a
Realtek USB Card Reader (0bda:0152), which has a max LUN of 3 but is set
to 0, thus losing functionality, because of the timeout occurring too
quickly.

Raising the timeout value fixes the issue and might help other devices
to return a correct max LUN value as well.

Signed-off-by: Giacomo Lozito <james@develia.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Fix option_ms regression in 2.6.31-rc2 2009-07-12T22:16:40+00:00 Jonathan McDowell noodles@earth.li 2009-07-05T11:29:51+00:00 2ab2178c3303583a0551f6b6bf4ba070afbf875f Commit 32ebbe7b6ad44ae9c276419710b56de6ba705303 which filters the SCSI REZERO command in option_ms based on a SCSI INQUIRY with a vendor of Option breaks my Option Icon 225 (0af0:6971). This device returns a vendor of ZCOPTION for the ZeroCD device. The following trivial patch fixes things for me. Signed-Off-By: Jonathan McDowell <noodles@earth.li> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Commit 32ebbe7b6ad44ae9c276419710b56de6ba705303 which filters the
SCSI REZERO command in option_ms based on a SCSI INQUIRY with a vendor
of Option breaks my Option Icon 225 (0af0:6971). This device returns a
vendor of ZCOPTION for the ZeroCD device. The following trivial patch
fixes things for me.

Signed-Off-By: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: usb-storage: add filter to "option_ms" to leave unrecognized devices alone 2009-06-16T04:44:46+00:00 Josua Dietze digidietze@draisberghof.de 2009-05-24T21:21:42+00:00 32ebbe7b6ad44ae9c276419710b56de6ba705303 Some unusual usb devices from the maker "Option" are switched from storage to serial/modem mode by sending a SCSI REZERO command. In one case a fairly common vendor/device ID is affected which led to problems for users of other modems or phones which are not supposed to be switched. The patch adds a filter by reading the vendor name with the SCSI INQUIRY command, and skips the switching code for all unrecognized entries. Further changes are cleanups and corrections pointed out by Alan Stern. Tested with two devices with the IDs 05c6:1000, one from "Option" and switchable, and one from Samsung (cell phone). Signed-off-by: Josua Dietze <digidietze@draisberghof.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Some unusual usb devices from the maker "Option" are switched from
storage to serial/modem mode by sending a SCSI REZERO command. In one
case a fairly common vendor/device ID is affected which led to problems
for users of other modems or phones which are not supposed to be
switched.

The patch adds a filter by reading the vendor name with the SCSI INQUIRY
command, and skips the switching code for all unrecognized entries.

Further changes are cleanups and corrections pointed out by Alan Stern.

Tested with two devices with the IDs 05c6:1000, one from "Option" and
switchable, and one from Samsung (cell phone).


Signed-off-by: Josua Dietze <digidietze@draisberghof.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>