<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mmc, branch v3.18.49</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mmc: sdhci: Fix recovery from tuning timeout</title>
<updated>2017-01-15T14:49:50+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-12-02T13:14:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6fe5845642c77a39519e177569791c8e05658e8c'/>
<id>6fe5845642c77a39519e177569791c8e05658e8c</id>
<content type='text'>
[ Upstream commit 61e53bd0047d58caee0c7170613045bf96de4458 ]

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Tested-by: Dan O'Donovan &lt;dan@emutex.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 61e53bd0047d58caee0c7170613045bf96de4458 ]

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Tested-by: Dan O'Donovan &lt;dan@emutex.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led</title>
<updated>2016-11-24T02:30:37+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2016-09-15T12:46:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b2580c4ba788bd913759b14dc9f5a9ef2ada997d'/>
<id>b2580c4ba788bd913759b14dc9f5a9ef2ada997d</id>
<content type='text'>
[ Upstream commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 ]

Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.

Reported-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Tested-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 ]

Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.

Reported-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Tested-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused</title>
<updated>2016-11-24T02:30:31+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2016-09-27T15:44:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=29cce652d7f43481a8cab30d94b73304849ce1cb'/>
<id>29cce652d7f43481a8cab30d94b73304849ce1cb</id>
<content type='text'>
[ Upstream commit 31cf742f515c275d22843c4c756e048d2b6d716c ]

The rtsx_usb_sdmmc driver may bail out in its -&gt;set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.

Tested-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 31cf742f515c275d22843c4c756e048d2b6d716c ]

The rtsx_usb_sdmmc driver may bail out in its -&gt;set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.

Tested-by: Ritesh Raj Sarraf &lt;rrs@researchut.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error</title>
<updated>2016-11-24T02:30:25+00:00</updated>
<author>
<name>Haibo Chen</name>
<email>haibo.chen@nxp.com</email>
</author>
<published>2016-10-17T08:18:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ee23181095ce57c85f070c5cac509b1da304e1d'/>
<id>3ee23181095ce57c85f070c5cac509b1da304e1d</id>
<content type='text'>
[ Upstream commit 02265cd60335a2c1417abae4192611e1fc05a6e5 ]

Potentially overflowing expression 1000000 * data-&gt;timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.

To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.

Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Cc: stable@vger.kernel.org # v3.15+
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 02265cd60335a2c1417abae4192611e1fc05a6e5 ]

Potentially overflowing expression 1000000 * data-&gt;timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.

To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.

Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen &lt;haibo.chen@nxp.com&gt;
Cc: stable@vger.kernel.org # v3.15+
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Annotate cmd_hdr as __le32</title>
<updated>2016-11-24T02:28:25+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2016-10-03T08:58:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a2ede59ea828df9616e3c7619252875912ea872'/>
<id>4a2ede59ea828df9616e3c7619252875912ea872</id>
<content type='text'>
[ Upstream commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 ]

Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.

But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] &lt;noident&gt;
drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] &lt;noident&gt;
...

So annotate cmd_hdr properly using __le32 to make everyone happy.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 ]

Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.

But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] &lt;noident&gt;
drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] &lt;noident&gt;
...

So annotate cmd_hdr properly using __le32 to make everyone happy.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: block: fix packed command header endianness</title>
<updated>2016-08-08T01:58:51+00:00</updated>
<author>
<name>Taras Kondratiuk</name>
<email>takondra@cisco.com</email>
</author>
<published>2016-07-13T22:05:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e18fa5ad02a5920c8582c6e0401ba4f570ede8a0'/>
<id>e18fa5ad02a5920c8582c6e0401ba4f570ede8a0</id>
<content type='text'>
[ Upstream commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 ]

The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:

[  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1

Convert header data to LE.

Signed-off-by: Taras Kondratiuk &lt;takondra@cisco.com&gt;
Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f68381a70bb2b26c31b13fdaf67c778f92fd32b4 ]

The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:

[  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1

Convert header data to LE.

Signed-off-by: Taras Kondratiuk &lt;takondra@cisco.com&gt;
Fixes: ce39f9d17c14 ("mmc: support packed write command for eMMC4.5 devices")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers</title>
<updated>2016-06-06T23:11:11+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-05-20T07:33:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4433e3758946d2e38933765f41716bfc6c1cc3ac'/>
<id>4433e3758946d2e38933765f41716bfc6c1cc3ac</id>
<content type='text'>
[ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ]

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 265984b36ce82fec67957d452dd2b22e010611e4 ]

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-acpi: Add two host capabilities for Intel</title>
<updated>2016-06-06T23:11:11+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2014-12-01T13:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15d0023ea50bd51d2f74196c986728d13db877a1'/>
<id>15d0023ea50bd51d2f74196c986728d13db877a1</id>
<content type='text'>
[ Upstream commit 9d65cb88e5979d43f47c899601353ca61973ba90 ]

Intel host controllers are capable of doing the bus
width test and of waiting while busy, so add the
capability flags.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9d65cb88e5979d43f47c899601353ca61973ba90 ]

Intel host controllers are capable of doing the bus
width test and of waiting while busy, so add the
capability flags.

Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: longer timeout for long read time quirk</title>
<updated>2016-06-06T23:11:10+00:00</updated>
<author>
<name>Matt Gumbel</name>
<email>matthew.k.gumbel@intel.com</email>
</author>
<published>2016-05-20T07:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ee0fc86c277a4cae05780764757e8ab97c12c7c9'/>
<id>ee0fc86c277a4cae05780764757e8ab97c12c7c9</id>
<content type='text'>
[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel &lt;matthew.k.gumbel@intel.com&gt;
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 32ecd320db39bcb007679ed42f283740641b81ea ]

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk

Signed-off-by: Matt Gumbel &lt;matthew.k.gumbel@intel.com&gt;
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mmc: Fix partition switch timeout for some eMMCs</title>
<updated>2016-06-06T23:11:05+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2016-05-05T05:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ae96721fa92dd8c7d3adfdab6c5566cf6a63a6a3'/>
<id>ae96721fa92dd8c7d3adfdab6c5566cf6a63a6a3</id>
<content type='text'>
[ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 ]

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
