<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mmc/host, branch linux-6.8.y</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-of-dwcmshc: th1520: Increase tuning loop count to 128</title>
<updated>2024-05-02T14:35:26+00:00</updated>
<author>
<name>Maksim Kiselev</name>
<email>bigunclemax@gmail.com</email>
</author>
<published>2024-04-02T09:35:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7778de90d58e28d86452ee0843cb4d319800ce3d'/>
<id>7778de90d58e28d86452ee0843cb4d319800ce3d</id>
<content type='text'>
commit ace323f80b9bc6734289a4e8a77938a3ce964c7d upstream.

Fix SD card tuning error by increasing tuning loop count
from 40(MAX_TUNING_LOOP) to 128.

For some reason the tuning algorithm requires to move through all the taps
of delay line even if the THRESHOLD_MODE (bit 2 in AT_CTRL_R) is used
instead of the LARGEST_WIN_MODE.

Tested-by: Drew Fustini &lt;drew@pdp7.com&gt;
Tested-by: Xi Ruoyao &lt;xry111@xry111.site&gt;
Signed-off-by: Maksim Kiselev &lt;bigunclemax@gmail.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: 43658a542ebf ("mmc: sdhci-of-dwcmshc: Add support for T-Head TH1520")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240402093539.184287-1-bigunclemax@gmail.com
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 ace323f80b9bc6734289a4e8a77938a3ce964c7d upstream.

Fix SD card tuning error by increasing tuning loop count
from 40(MAX_TUNING_LOOP) to 128.

For some reason the tuning algorithm requires to move through all the taps
of delay line even if the THRESHOLD_MODE (bit 2 in AT_CTRL_R) is used
instead of the LARGEST_WIN_MODE.

Tested-by: Drew Fustini &lt;drew@pdp7.com&gt;
Tested-by: Xi Ruoyao &lt;xry111@xry111.site&gt;
Signed-off-by: Maksim Kiselev &lt;bigunclemax@gmail.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: 43658a542ebf ("mmc: sdhci-of-dwcmshc: Add support for T-Head TH1520")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240402093539.184287-1-bigunclemax@gmail.com
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-msm: pervent access to suspended controller</title>
<updated>2024-05-02T14:35:26+00:00</updated>
<author>
<name>Mantas Pucka</name>
<email>mantas@8devices.com</email>
</author>
<published>2024-03-21T14:30:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f653b04a818c490b045c97834d559911479aa1c5'/>
<id>f653b04a818c490b045c97834d559911479aa1c5</id>
<content type='text'>
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.

Generic sdhci code registers LED device and uses host-&gt;runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.

Cc: stable@vger.kernel.org
Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support")
Signed-off-by: Mantas Pucka &lt;mantas@8devices.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com
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 f8def10f73a516b771051a2f70f2f0446902cb4f upstream.

Generic sdhci code registers LED device and uses host-&gt;runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.

Cc: stable@vger.kernel.org
Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support")
Signed-off-by: Mantas Pucka &lt;mantas@8devices.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com
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: omap: restore original power up/down steps</title>
<updated>2024-04-17T09:23:26+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2024-02-23T18:14:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bcf70697acbc9f605d5514f0e60c316b25a5b5b2'/>
<id>bcf70697acbc9f605d5514f0e60c316b25a5b5b2</id>
<content type='text'>
[ Upstream commit 894ad61b85d6ba8efd4274aa8719d9ff1c89ea54 ]

Commit e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
moved Nokia N810 MMC power up/down from the board file into the MMC driver.

The change removed some delays, and ordering without a valid reason.
Restore power up/down to match the original code. This matters only on N810
where the 2nd GPIO is in use. Other boards will see an additional delay but
that should be a lesser concern than omitting delays altogether.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-6-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 894ad61b85d6ba8efd4274aa8719d9ff1c89ea54 ]

Commit e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
moved Nokia N810 MMC power up/down from the board file into the MMC driver.

The change removed some delays, and ordering without a valid reason.
Restore power up/down to match the original code. This matters only on N810
where the 2nd GPIO is in use. Other boards will see an additional delay but
that should be a lesser concern than omitting delays altogether.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-6-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: omap: fix deferred probe</title>
<updated>2024-04-17T09:23:26+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2024-02-23T18:14:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e2119120a5ac91e462d8d5bb693b3ec6b72e24e8'/>
<id>e2119120a5ac91e462d8d5bb693b3ec6b72e24e8</id>
<content type='text'>
[ Upstream commit f6862c7f156d04f81c38467e1c304b7e9517e810 ]

After a deferred probe, GPIO descriptor lookup will fail with EBUSY. Fix by
using managed descriptors.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-5-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f6862c7f156d04f81c38467e1c304b7e9517e810 ]

After a deferred probe, GPIO descriptor lookup will fail with EBUSY. Fix by
using managed descriptors.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-5-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: omap: fix broken slot switch lookup</title>
<updated>2024-04-17T09:23:26+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2024-02-23T18:14:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2020c5d72a4a084c054e4f551a54fdc5360797e9'/>
<id>2020c5d72a4a084c054e4f551a54fdc5360797e9</id>
<content type='text'>
[ Upstream commit d4debbcbffa45c3de5df0040af2eea74a9e794a3 ]

The lookup is done before host-&gt;dev is initialized. It will always just
fail silently, and the MMC behaviour is totally unpredictable as the switch
is left in an undefined state. Fix that.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-4-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit d4debbcbffa45c3de5df0040af2eea74a9e794a3 ]

The lookup is done before host-&gt;dev is initialized. It will always just
fail silently, and the MMC behaviour is totally unpredictable as the switch
is left in an undefined state. Fix that.

Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Message-ID: &lt;20240223181439.1099750-4-aaro.koskinen@iki.fi&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sdhci-of-dwcmshc: disable PM runtime in dwcmshc_remove()</title>
<updated>2024-04-03T13:32:40+00:00</updated>
<author>
<name>Liming Sun</name>
<email>limings@nvidia.com</email>
</author>
<published>2024-03-19T16:16:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f9985102f4f1c1653e47ff997f5f722c20078d79'/>
<id>f9985102f4f1c1653e47ff997f5f722c20078d79</id>
<content type='text'>
commit 03749309909935070253accab314288d332a204d upstream.

This commit disables PM runtime in dwcmshc_remove() to avoid the
error message below when reloading the sdhci-of-dwcmshc.ko

  sdhci-dwcmshc MLNXBF30:00: Unbalanced pm_runtime_enable!

Fixes: 48fe8fadbe5e ("mmc: sdhci-of-dwcmshc: Add runtime PM operations")
Reviewed-by: David Thompson &lt;davthompson@nvidia.com&gt;
Signed-off-by: Liming Sun &lt;limings@nvidia.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b9155963ffb12d18375002bf9ac9a3f98b727fc8.1710854108.git.limings@nvidia.com
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 03749309909935070253accab314288d332a204d upstream.

This commit disables PM runtime in dwcmshc_remove() to avoid the
error message below when reloading the sdhci-of-dwcmshc.ko

  sdhci-dwcmshc MLNXBF30:00: Unbalanced pm_runtime_enable!

Fixes: 48fe8fadbe5e ("mmc: sdhci-of-dwcmshc: Add runtime PM operations")
Reviewed-by: David Thompson &lt;davthompson@nvidia.com&gt;
Signed-off-by: Liming Sun &lt;limings@nvidia.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b9155963ffb12d18375002bf9ac9a3f98b727fc8.1710854108.git.limings@nvidia.com
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-omap: re-tuning is needed after a pm transition to support emmc HS200 mode</title>
<updated>2024-04-03T13:32:40+00:00</updated>
<author>
<name>Romain Naour</name>
<email>romain.naour@skf.com</email>
</author>
<published>2024-03-15T23:44:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd1e70a58298ef6b851833be70321447e35812fa'/>
<id>bd1e70a58298ef6b851833be70321447e35812fa</id>
<content type='text'>
commit f9e2a5b00a35f2c064dc679808bc8db5cc779ed6 upstream.

"PM runtime functions" was been added in sdhci-omap driver in commit
f433e8aac6b9 ("mmc: sdhci-omap: Implement PM runtime functions") along
with "card power off and enable aggressive PM" in commit 3edf588e7fe0
("mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PM").

Since then, the sdhci-omap driver doesn't work using mmc-hs200 mode
due to the tuning values being lost during a pm transition.

As for the sdhci_am654 driver, request a new tuning sequence before
suspend (sdhci_omap_runtime_suspend()), otherwise the device will
trigger cache flush error:

  mmc1: cache flush error -110 (ETIMEDOUT)
  mmc1: error -110 doing aggressive suspend

followed by I/O errors produced by fdisk -l /dev/mmcblk1boot1:

  I/O error, dev mmcblk1boot0, sector 64384 op 0x0:(READ) flags 0x80700 phys_seg 1
  prio class 2
  I/O error, dev mmcblk1boot1, sector 64384 op 0x0:(READ) flags 0x80700 phys_seg 1
  prio class 2
  I/O error, dev mmcblk1boot1, sector 64384 op 0x0:(READ) flags 0x0 phys_seg 1
  prio class 2
  Buffer I/O error on dev mmcblk1boot1, logical block 8048, async page read
  I/O error, dev mmcblk1boot0, sector 64384 op 0x0:(READ) flags 0x0 phys_seg 1
  prio class 2
  Buffer I/O error on dev mmcblk1boot0, logical block 8048, async page read

Don't re-tune if auto retuning is supported in HW (when SDHCI_TUNING_MODE_3
is available).

Link: https://lore.kernel.org/all/2e5f1997-564c-44e4-b357-6343e0dae7ab@smile.fr
Fixes: f433e8aac6b9 ("mmc: sdhci-omap: Implement PM runtime functions")
Signed-off-by: Romain Naour &lt;romain.naour@skf.com&gt;
Reviewed-by: Tony Lindgren &lt;tony@atomide.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240315234444.816978-1-romain.naour@smile.fr
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 f9e2a5b00a35f2c064dc679808bc8db5cc779ed6 upstream.

"PM runtime functions" was been added in sdhci-omap driver in commit
f433e8aac6b9 ("mmc: sdhci-omap: Implement PM runtime functions") along
with "card power off and enable aggressive PM" in commit 3edf588e7fe0
("mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PM").

Since then, the sdhci-omap driver doesn't work using mmc-hs200 mode
due to the tuning values being lost during a pm transition.

As for the sdhci_am654 driver, request a new tuning sequence before
suspend (sdhci_omap_runtime_suspend()), otherwise the device will
trigger cache flush error:

  mmc1: cache flush error -110 (ETIMEDOUT)
  mmc1: error -110 doing aggressive suspend

followed by I/O errors produced by fdisk -l /dev/mmcblk1boot1:

  I/O error, dev mmcblk1boot0, sector 64384 op 0x0:(READ) flags 0x80700 phys_seg 1
  prio class 2
  I/O error, dev mmcblk1boot1, sector 64384 op 0x0:(READ) flags 0x80700 phys_seg 1
  prio class 2
  I/O error, dev mmcblk1boot1, sector 64384 op 0x0:(READ) flags 0x0 phys_seg 1
  prio class 2
  Buffer I/O error on dev mmcblk1boot1, logical block 8048, async page read
  I/O error, dev mmcblk1boot0, sector 64384 op 0x0:(READ) flags 0x0 phys_seg 1
  prio class 2
  Buffer I/O error on dev mmcblk1boot0, logical block 8048, async page read

Don't re-tune if auto retuning is supported in HW (when SDHCI_TUNING_MODE_3
is available).

Link: https://lore.kernel.org/all/2e5f1997-564c-44e4-b357-6343e0dae7ab@smile.fr
Fixes: f433e8aac6b9 ("mmc: sdhci-omap: Implement PM runtime functions")
Signed-off-by: Romain Naour &lt;romain.naour@skf.com&gt;
Reviewed-by: Tony Lindgren &lt;tony@atomide.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240315234444.816978-1-romain.naour@smile.fr
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: avoid concurrent runs of mmc_request_done()</title>
<updated>2024-04-03T13:32:11+00:00</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2024-03-05T10:42:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=842cf1ab756aaa5ee67ce2f0cc0f8925367e9760'/>
<id>842cf1ab756aaa5ee67ce2f0cc0f8925367e9760</id>
<content type='text'>
[ Upstream commit e8d1b41e69d72c62865bebe8f441163ec00b3d44 ]

With the to-be-fixed commit, the reset_work handler cleared 'host-&gt;mrq'
outside of the spinlock protected critical section. That leaves a small
race window during execution of 'tmio_mmc_reset()' where the done_work
handler could grab a pointer to the now invalid 'host-&gt;mrq'. Both would
use it to call mmc_request_done() causing problems (see link below).

However, 'host-&gt;mrq' cannot simply be cleared earlier inside the
critical section. That would allow new mrqs to come in asynchronously
while the actual reset of the controller still needs to be done. So,
like 'tmio_mmc_set_ios()', an ERR_PTR is used to prevent new mrqs from
coming in but still avoiding concurrency between work handlers.

Reported-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Closes: https://lore.kernel.org/all/20240220061356.3001761-1-dirk.behme@de.bosch.com/
Fixes: df3ef2d3c92c ("mmc: protect the tmio_mmc driver against a theoretical race")
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Tested-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Reviewed-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Cc: stable@vger.kernel.org # 3.0+
Link: https://lore.kernel.org/r/20240305104423.3177-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e8d1b41e69d72c62865bebe8f441163ec00b3d44 ]

With the to-be-fixed commit, the reset_work handler cleared 'host-&gt;mrq'
outside of the spinlock protected critical section. That leaves a small
race window during execution of 'tmio_mmc_reset()' where the done_work
handler could grab a pointer to the now invalid 'host-&gt;mrq'. Both would
use it to call mmc_request_done() causing problems (see link below).

However, 'host-&gt;mrq' cannot simply be cleared earlier inside the
critical section. That would allow new mrqs to come in asynchronously
while the actual reset of the controller still needs to be done. So,
like 'tmio_mmc_set_ios()', an ERR_PTR is used to prevent new mrqs from
coming in but still avoiding concurrency between work handlers.

Reported-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Closes: https://lore.kernel.org/all/20240220061356.3001761-1-dirk.behme@de.bosch.com/
Fixes: df3ef2d3c92c ("mmc: protect the tmio_mmc driver against a theoretical race")
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Tested-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Reviewed-by: Dirk Behme &lt;dirk.behme@de.bosch.com&gt;
Cc: stable@vger.kernel.org # 3.0+
Link: https://lore.kernel.org/r/20240305104423.3177-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove function</title>
<updated>2024-03-26T22:16:51+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2024-02-26T21:37:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fc0cc76f551cfb283aa457f7ca0459ba2ebea825'/>
<id>fc0cc76f551cfb283aa457f7ca0459ba2ebea825</id>
<content type='text'>
[ Upstream commit ae5004a40a262d329039b99b62bd3fe7645b66ad ]

This looks strange to call release_mem_region() in a remove function
without any request_mem_region() in the probe or "struct resource"
somewhere.

So remove the corresponding code.

Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.1708983064.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ae5004a40a262d329039b99b62bd3fe7645b66ad ]

This looks strange to call release_mem_region() in a remove function
without any request_mem_region() in the probe or "struct resource"
somewhere.

So remove the corresponding code.

Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.1708983064.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-xenon: add timeout for PHY init complete</title>
<updated>2024-02-28T12:41:35+00:00</updated>
<author>
<name>Elad Nachman</name>
<email>enachman@marvell.com</email>
</author>
<published>2024-02-22T19:17:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=09e23823ae9a3e2d5d20f2e1efe0d6e48cef9129'/>
<id>09e23823ae9a3e2d5d20f2e1efe0d6e48cef9129</id>
<content type='text'>
AC5X spec says PHY init complete bit must be polled until zero.
We see cases in which timeout can take longer than the standard
calculation on AC5X, which is expected following the spec comment above.
According to the spec, we must wait as long as it takes for that bit to
toggle on AC5X.
Cap that with 100 delay loops so we won't get stuck forever.

Fixes: 06c8b667ff5b ("mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC")
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Elad Nachman &lt;enachman@marvell.com&gt;
Link: https://lore.kernel.org/r/20240222191714.1216470-3-enachman@marvell.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
AC5X spec says PHY init complete bit must be polled until zero.
We see cases in which timeout can take longer than the standard
calculation on AC5X, which is expected following the spec comment above.
According to the spec, we must wait as long as it takes for that bit to
toggle on AC5X.
Cap that with 100 delay loops so we won't get stuck forever.

Fixes: 06c8b667ff5b ("mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC")
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Elad Nachman &lt;enachman@marvell.com&gt;
Link: https://lore.kernel.org/r/20240222191714.1216470-3-enachman@marvell.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
