<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/usb/storage, branch v3.4.80</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/usb/storage?h=v3.4.80</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/usb/storage?h=v3.4.80'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-02-06T19:05:46Z</updated>
<entry>
<title>USB: Nokia 502 is an unusual device</title>
<updated>2014-02-06T19:05:46Z</updated>
<author>
<name>Mikhail Zolotaryov</name>
<email>lebon@lebon.org.ua</email>
</author>
<published>2013-12-27T23:56:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0c18e8161aa0e9083a12c86106d0bbe19591c29e'/>
<id>urn:sha1:0c18e8161aa0e9083a12c86106d0bbe19591c29e</id>
<content type='text'>
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 &amp;&amp; modprobe usb_storage quirks=0421:06aa:m

The patch adds the tested device to the unusual list permanently.

Signed-off-by: Mikhail Zolotaryov &lt;lebon@lebon.org.ua&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: storage: Add MicroVault Flash Drive to unusual_devs</title>
<updated>2013-08-04T08:25:42Z</updated>
<author>
<name>Ren Bigcren</name>
<email>bigcren.ren@sonymobile.com</email>
</author>
<published>2013-07-02T11:34:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=975e6b1a5a5c74c91cf5a57932ff348576d1268d'/>
<id>urn:sha1:975e6b1a5a5c74c91cf5a57932ff348576d1268d</id>
<content type='text'>
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 &lt;bigcren.ren@sonymobile.com&gt;
Cc: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
Signed-off-by: Oskar Andero &lt;oskar.andero@sonymobile.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb-storage: CY7C68300A chips do not support Cypress ATACB</title>
<updated>2013-05-08T02:51:53Z</updated>
<author>
<name>Tormod Volden</name>
<email>debian.tormod@gmail.com</email>
</author>
<published>2013-04-20T12:24:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d7200993dd8d12775487157913b5e6ce866e642f'/>
<id>urn:sha1:d7200993dd8d12775487157913b5e6ce866e642f</id>
<content type='text'>
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 &lt;debian.tormod@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb-storage: add unusual_devs entry for Samsung YP-Z3 mp3 player</title>
<updated>2013-03-28T19:12:25Z</updated>
<author>
<name>Dmitry Artamonow</name>
<email>mad_soft@inbox.ru</email>
</author>
<published>2013-03-09T16:30:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=120c3558614078cbde7fb0d40a3e7db2d63b660b'/>
<id>urn:sha1:120c3558614078cbde7fb0d40a3e7db2d63b660b</id>
<content type='text'>
commit 29f86e66428ee083aec106cca1748dc63d98ce23 upstream.

Device stucks on filesystem writes, unless following quirk is passed:
  echo 04e8:5136:m &gt; /sys/module/usb_storage/parameters/quirks

Add corresponding entry to unusual_devs.h

Signed-off-by: Dmitry Artamonow &lt;mad_soft@inbox.ru&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: storage: fix Huawei mode switching regression</title>
<updated>2013-03-20T20:04:58Z</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2013-03-04T13:19:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0b520a5db298be1d1e74b8e51a02d73e1dbf6045'/>
<id>urn:sha1:0b520a5db298be1d1e74b8e51a02d73e1dbf6045</id>
<content type='text'>
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 &lt;bjorn@mork.no&gt;
Cc: &lt;fangxiaozhi@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: usb-storage: unusual_devs update for Super TOP SATA bridge</title>
<updated>2013-02-28T14:59:07Z</updated>
<author>
<name>Josh Boyer</name>
<email>jwboyer@redhat.com</email>
</author>
<published>2013-02-14T14:39:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=616dd23b2e475e61a2974eb112cc88d3cb94d47f'/>
<id>urn:sha1:616dd23b2e475e61a2974eb112cc88d3cb94d47f</id>
<content type='text'>
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. &lt;carsteniq@yahoo.com&gt;
Tested-by: Carsten S. &lt;carsteniq@yahoo.com&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: storage: properly handle the endian issues of idProduct</title>
<updated>2013-02-28T14:59:07Z</updated>
<author>
<name>fangxiaozhi</name>
<email>huananhu@huawei.com</email>
</author>
<published>2013-02-07T07:32:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=12b64a247ef45dcd865a98d63bbae7355e51633b'/>
<id>urn:sha1:12b64a247ef45dcd865a98d63bbae7355e51633b</id>
<content type='text'>
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 &lt;huananhu@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: storage: optimize to match the Huawei USB storage devices and support new switch command</title>
<updated>2013-02-11T16:47:20Z</updated>
<author>
<name>fangxiaozhi</name>
<email>huananhu@huawei.com</email>
</author>
<published>2013-02-04T07:16:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c42fc5a5c545964d97b3c0910ab7c30672155d04'/>
<id>urn:sha1:c42fc5a5c545964d97b3c0910ab7c30672155d04</id>
<content type='text'>
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 &lt;huananhu@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: storage: Define a new macro for USB storage match rules</title>
<updated>2013-02-11T16:47:20Z</updated>
<author>
<name>fangxiaozhi</name>
<email>huananhu@huawei.com</email>
</author>
<published>2013-02-04T07:14:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fae3bb5e23fef7eee49545341601a407c090cf88'/>
<id>urn:sha1:fae3bb5e23fef7eee49545341601a407c090cf88</id>
<content type='text'>
commit 07c7be3d87e5cdaf5f94c271c516456364ef286c upstream.

1. Define a new macro for USB storage match rules:
    matching with Vendor ID and interface descriptors.

Signed-off-by: fangxiaozhi &lt;huananhu@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: mark uas driver as BROKEN</title>
<updated>2012-12-17T18:37:45Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-11-28T18:19:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=46c117c706ef4f4086cbe24d24fd0f19551e96bd'/>
<id>urn:sha1:46c117c706ef4f4086cbe24d24fd0f19551e96bd</id>
<content type='text'>
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 &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
