<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mmc, branch v4.16.4</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-pci: Only do AMD tuning for HS200</title>
<updated>2018-04-24T07:43:09+00:00</updated>
<author>
<name>Daniel Kurtz</name>
<email>djkurtz@chromium.org</email>
</author>
<published>2018-04-06T22:07:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b7116e86a534aa3ee774d71f95c13f2b8ed02a1e'/>
<id>b7116e86a534aa3ee774d71f95c13f2b8ed02a1e</id>
<content type='text'>
commit 300ad8992913025b4294d4fc37b6bfff4a8b7ad1 upstream.

Commit c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode
on AMD, eMMC-4.5.1") added a HS200 tuning method for use with AMD SDHCI
controllers.  As described in the commit subject, this tuning is specific
for HS200.  However, as implemented, this method is used for all host
timings, because platform_execute_tuning, if it exists, is called
unconditionally by sdhci_execute_tuning().  This breaks tuning when using
the AMD controller with, for example, a DDR50 SD card.

Instead, we can implement an amd execute_tuning wrapper callback, and
then conditionally do the HS200 specific tuning for HS200, and otherwise
call back to the standard sdhci_execute_tuning().

Signed-off-by: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Acked-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode on AMD, eMMC-4.5.1")
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 300ad8992913025b4294d4fc37b6bfff4a8b7ad1 upstream.

Commit c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode
on AMD, eMMC-4.5.1") added a HS200 tuning method for use with AMD SDHCI
controllers.  As described in the commit subject, this tuning is specific
for HS200.  However, as implemented, this method is used for all host
timings, because platform_execute_tuning, if it exists, is called
unconditionally by sdhci_execute_tuning().  This breaks tuning when using
the AMD controller with, for example, a DDR50 SD card.

Instead, we can implement an amd execute_tuning wrapper callback, and
then conditionally do the HS200 specific tuning for HS200, and otherwise
call back to the standard sdhci_execute_tuning().

Signed-off-by: Daniel Kurtz &lt;djkurtz@chromium.org&gt;
Acked-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode on AMD, eMMC-4.5.1")
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: tmio: Fix error handling when issuing CMD23</title>
<updated>2018-04-24T07:43:03+00:00</updated>
<author>
<name>Masaharu Hayakawa</name>
<email>masaharu.hayakawa.ry@renesas.com</email>
</author>
<published>2018-04-03T21:57:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b42a321adc7281d4091e1caa3d6a4237957a0934'/>
<id>b42a321adc7281d4091e1caa3d6a4237957a0934</id>
<content type='text'>
commit fc167daff581c01ebce8695e9618231cae3561a1 upstream.

If an error was detected when CMD23 was issued, command sequence should
be terminated with errors and CMD23 should be issued after retuning.

Fixes: 8b22c3c18be5 ("mmc: tmio: add CMD23 support")
Signed-off-by: Masaharu Hayakawa &lt;masaharu.hayakawa.ry@renesas.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.13+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fc167daff581c01ebce8695e9618231cae3561a1 upstream.

If an error was detected when CMD23 was issued, command sequence should
be terminated with errors and CMD23 should be issued after retuning.

Fixes: 8b22c3c18be5 ("mmc: tmio: add CMD23 support")
Signed-off-by: Masaharu Hayakawa &lt;masaharu.hayakawa.ry@renesas.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.13+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: jz4740: Fix race condition in IRQ mask update</title>
<updated>2018-04-24T07:43:03+00:00</updated>
<author>
<name>Alex Smith</name>
<email>alex.smith@imgtec.com</email>
</author>
<published>2018-03-28T21:00:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7809401a616f108e7d7a7fc44dc04426a5ca9ff4'/>
<id>7809401a616f108e7d7a7fc44dc04426a5ca9ff4</id>
<content type='text'>
commit a04f0017c22453613d5f423326b190c61e3b4f98 upstream.

A spinlock is held while updating the internal copy of the IRQ mask,
but not while writing it to the actual IMASK register. After the lock
is released, an IRQ can occur before the IMASK register is written.
If handling this IRQ causes the mask to be changed, when the handler
returns back to the middle of the first mask update, a stale value
will be written to the mask register.

If this causes an IRQ to become unmasked that cannot have its status
cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ,
then we can end up stuck with the same IRQ repeatedly being fired but
not handled. Normally the MMC IRQ handler attempts to clear any
unexpected IRQs by writing IREG, but for those that cannot be cleared
in this way then the IRQ will just repeatedly fire.

This was resulting in lockups after a while of using Wi-Fi on the
CI20 (GitHub issue #19).

Resolve by holding the spinlock until after the IMASK register has
been updated.

Cc: stable@vger.kernel.org
Link: https://github.com/MIPS/CI20_linux/issues/19
Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")
Tested-by: Mathieu Malaterre &lt;malat@debian.org&gt;
Signed-off-by: Alex Smith &lt;alex.smith@imgtec.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a04f0017c22453613d5f423326b190c61e3b4f98 upstream.

A spinlock is held while updating the internal copy of the IRQ mask,
but not while writing it to the actual IMASK register. After the lock
is released, an IRQ can occur before the IMASK register is written.
If handling this IRQ causes the mask to be changed, when the handler
returns back to the middle of the first mask update, a stale value
will be written to the mask register.

If this causes an IRQ to become unmasked that cannot have its status
cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ,
then we can end up stuck with the same IRQ repeatedly being fired but
not handled. Normally the MMC IRQ handler attempts to clear any
unexpected IRQs by writing IREG, but for those that cannot be cleared
in this way then the IRQ will just repeatedly fire.

This was resulting in lockups after a while of using Wi-Fi on the
CI20 (GitHub issue #19).

Resolve by holding the spinlock until after the IMASK register has
been updated.

Cc: stable@vger.kernel.org
Link: https://github.com/MIPS/CI20_linux/issues/19
Fixes: 61bfbdb85687 ("MMC: Add support for the controller on JZ4740 SoCs.")
Tested-by: Mathieu Malaterre &lt;malat@debian.org&gt;
Signed-off-by: Alex Smith &lt;alex.smith@imgtec.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Prevent bus reference leak in mmc_blk_init()</title>
<updated>2018-04-24T07:43:03+00:00</updated>
<author>
<name>Alexander Kappner</name>
<email>agk@godking.net</email>
</author>
<published>2018-03-28T22:18:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=723bee23e8ba89b2208b8f85634775bf838a43c4'/>
<id>723bee23e8ba89b2208b8f85634775bf838a43c4</id>
<content type='text'>
commit d0a0852b9f81cf5f793bf2eae7336ed40a1a1815 upstream.

Upon module load, mmc_block allocates a bus with bus_registeri() in
mmc_blk_init(). This reference never gets freed during module unload, which
leads to subsequent re-insertions of the module fails and a WARN() splat is
triggered.

Fix the bug by dropping the reference for the bus in mmc_blk_exit().

Signed-off-by: Alexander Kappner &lt;agk@godking.net&gt;
Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d0a0852b9f81cf5f793bf2eae7336ed40a1a1815 upstream.

Upon module load, mmc_block allocates a bus with bus_registeri() in
mmc_blk_init(). This reference never gets freed during module unload, which
leads to subsequent re-insertions of the module fails and a WARN() splat is
triggered.

Fix the bug by dropping the reference for the bus in mmc_blk_exit().

Signed-off-by: Alexander Kappner &lt;agk@godking.net&gt;
Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device")
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-acpi: Fix IRQ 0</title>
<updated>2018-03-21T10:10:20+00:00</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2018-03-21T09:49:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d58ac803cfbb92ede501409dd6afe9abb111d4f1'/>
<id>d58ac803cfbb92ede501409dd6afe9abb111d4f1</id>
<content type='text'>
Zero is a valid IRQ number and is being used on some CHT tablets. Stop
treating it as an error.

Reported-by: Luke Ross &lt;luke@lukeross.name&gt;
Fixes: 1b7ba57ecc86 ("mmc: sdhci-acpi: Handle return value of platform_get_irq")
Cc: Arvind Yadav &lt;arvind.yadav.cs@gmail.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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Zero is a valid IRQ number and is being used on some CHT tablets. Stop
treating it as an error.

Reported-by: Luke Ross &lt;luke@lukeross.name&gt;
Fixes: 1b7ba57ecc86 ("mmc: sdhci-acpi: Handle return value of platform_get_irq")
Cc: Arvind Yadav &lt;arvind.yadav.cs@gmail.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;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs</title>
<updated>2018-03-16T07:38:54+00:00</updated>
<author>
<name>Evgeniy Didin</name>
<email>Evgeniy.Didin@synopsys.com</email>
</author>
<published>2018-03-14T19:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47b7de2f6c18f75d1f2716efe752cba43f32a626'/>
<id>47b7de2f6c18f75d1f2716efe752cba43f32a626</id>
<content type='text'>
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.

That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.

Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.

Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.

And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().

Signed-off-by: Evgeniy Didin &lt;Evgeniy.Didin@synopsys.com&gt;
Cc: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Cc: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Jisheng Zhang &lt;Jisheng.Zhang@synaptics.com&gt;
Cc: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Cc: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Cc: linux-snps-arc@lists.infradead.org
Cc: &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.

That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.

Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.

Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.

And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().

Signed-off-by: Evgeniy Didin &lt;Evgeniy.Didin@synopsys.com&gt;
Cc: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Cc: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Cc: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Jisheng Zhang &lt;Jisheng.Zhang@synaptics.com&gt;
Cc: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Cc: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Cc: linux-snps-arc@lists.infradead.org
Cc: &lt;stable@vger.kernel.org&gt; # 4.4+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards</title>
<updated>2018-03-15T09:50:59+00:00</updated>
<author>
<name>Dirk Behme</name>
<email>dirk.behme@de.bosch.com</email>
</author>
<published>2018-03-14T14:50:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4'/>
<id>dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4</id>
<content type='text'>
Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.

Signed-off-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Signed-off-by: Mark Craske &lt;Mark_Craske@mentor.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

In U-Boot, these cards are reported as

Manufacturer: Micron (ID: 0xFE)
OEM: 0x4E
Name: MMC32G
Revision: 19 (0x13)
Serial: 959241022  Manufact. date: 8/2015 (0x82)  CRC: 0x00
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 29.1 GiB
Boot Partition Size: 16 MiB
Bus Width: 8-bit

According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
Micron.

Signed-off-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Signed-off-by: Mark Craske &lt;Mark_Craske@mentor.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.8+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433</title>
<updated>2018-03-15T09:34:30+00:00</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2018-03-09T06:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e22842dd64bf86753d3f2b6ea474d73fc1e6ca24'/>
<id>e22842dd64bf86753d3f2b6ea474d73fc1e6ca24</id>
<content type='text'>
Before enabling the clock, dwmmc exynos driver is trying to access the
register. Then the kernel panic can be occurred.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Tested-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before enabling the clock, dwmmc exynos driver is trying to access the
register. Then the kernel panic can be occurred.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Tested-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: block: fix updating ext_csd caches on ioctl call</title>
<updated>2018-03-15T09:31:38+00:00</updated>
<author>
<name>Bastian Stender</name>
<email>bst@pengutronix.de</email>
</author>
<published>2018-03-08T14:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e74ef2194b41ba5e511fab29fe5ff00e72d2f42a'/>
<id>e74ef2194b41ba5e511fab29fe5ff00e72d2f42a</id>
<content type='text'>
PARTITION_CONFIG is cached in mmc_card-&gt;ext_csd.part_config and the
currently active partition in mmc_blk_data-&gt;part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.

Signed-off-by: Bastian Stender &lt;bst@pengutronix.de&gt;
Signed-off-by: Jan Luebbe &lt;jlu@pengutronix.de&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PARTITION_CONFIG is cached in mmc_card-&gt;ext_csd.part_config and the
currently active partition in mmc_blk_data-&gt;part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.

Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.

Signed-off-by: Bastian Stender &lt;bst@pengutronix.de&gt;
Signed-off-by: Jan Luebbe &lt;jlu@pengutronix.de&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems</title>
<updated>2018-03-05T08:36:17+00:00</updated>
<author>
<name>Evgeniy Didin</name>
<email>Evgeniy.Didin@synopsys.com</email>
</author>
<published>2018-02-28T11:53:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c7151602255a36ba07c84fe2baeef846fdb988b8'/>
<id>c7151602255a36ba07c84fe2baeef846fdb988b8</id>
<content type='text'>
The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
made changes, which cause multiply overflow for 32-bit systems. The broken
timeout calculations leads to unexpected ETIMEDOUT errors and causes
stacktrace splat (such as below) during normal data exchange with SD-card.

| Running :  4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
| -  Info: Finished target initialization.
| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd
| response 0x900, card status 0x0

DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so
code gets compiled on all 32-bit platforms as opposed to usage of
DIV_ROUND_UP when we may only compile stuff on a very few arches.

Lets cast this multiply to u64 type to prevent the overflow.

Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
Tested-by: Vineet Gupta &lt;Vineet.Gupta1@synopsys.com&gt;
Reported-by: Vineet Gupta &lt;Vineet.Gupta1@synopsys.com&gt; # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
Signed-off-by: Evgeniy Didin &lt;Evgeniy.Didin@synopsys.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.14
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Reviewed-by: Jisheng Zhang &lt;Jisheng.Zhang@synaptics.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
made changes, which cause multiply overflow for 32-bit systems. The broken
timeout calculations leads to unexpected ETIMEDOUT errors and causes
stacktrace splat (such as below) during normal data exchange with SD-card.

| Running :  4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
| -  Info: Finished target initialization.
| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd
| response 0x900, card status 0x0

DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so
code gets compiled on all 32-bit platforms as opposed to usage of
DIV_ROUND_UP when we may only compile stuff on a very few arches.

Lets cast this multiply to u64 type to prevent the overflow.

Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
Tested-by: Vineet Gupta &lt;Vineet.Gupta1@synopsys.com&gt;
Reported-by: Vineet Gupta &lt;Vineet.Gupta1@synopsys.com&gt; # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
Signed-off-by: Evgeniy Didin &lt;Evgeniy.Didin@synopsys.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.14
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Reviewed-by: Jisheng Zhang &lt;Jisheng.Zhang@synaptics.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
