<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mmc/core, branch v5.15.209</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.209</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.209'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-01T15:35:16+00:00</updated>
<entry>
<title>mmc: block: use single block write in retry</title>
<updated>2026-06-01T15:35:16+00:00</updated>
<author>
<name>Bin Liu</name>
<email>b-liu@ti.com</email>
</author>
<published>2026-03-25T13:49:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb6978b426d07e4116b7ce78b71dcfcc527480c7'/>
<id>urn:sha1:bb6978b426d07e4116b7ce78b71dcfcc527480c7</id>
<content type='text'>
commit c7c6d4f5103864f73ee3a78bfd6da241f84197dd upstream.

Due to errata i2493[0], multi-block write would still fail in retries.

With i2493, the MMC interface has the potential of write failures when
issuing multi-block writes operating in HS200 mode with excessive IO
supply noise.

While the errata provides guidance in hardware design and layout to
minimize the IO supply noise, in theory the write failure cannot be
resolved in hardware. The software solution to ensure the data integrity
is to add minimum 5us delay between block writes. Single-block write is
the practical way to introduce the delay.

This patch reuses recovery_mode flag, and switches to single-block
write in retry when multi-block write fails. It covers both CQE and
non-CQE cases.

[0] https://www.ti.com/lit/pdf/sprz582
Cc: stable@vger.kernel.org
Suggested-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Bin Liu &lt;b-liu@ti.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>
</entry>
<entry>
<title>mmc: core: use sysfs_emit() instead of sprintf()</title>
<updated>2026-01-19T12:10:11+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omp.ru</email>
</author>
<published>2025-12-12T08:19:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f55ac683b2722714016f16daae9cab3f7f7b9f9'/>
<id>urn:sha1:0f55ac683b2722714016f16daae9cab3f7f7b9f9</id>
<content type='text'>
[ Upstream commit f5d8a5fe77ce933f53eb8f2e22bb7a1a2019ea11 ]

sprintf() (still used in the MMC core for the sysfs output) is vulnerable
to the buffer overflow.  Use the new-fangled sysfs_emit() instead.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omp.ru&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/717729b2-d65b-c72e-9fac-471d28d00b5a@omp.ru
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Chen Yu &lt;xnguchen@sina.cn&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: SPI mode remove cmd7</title>
<updated>2025-10-19T14:21:47+00:00</updated>
<author>
<name>Rex Chen</name>
<email>rex.chen_1@nxp.com</email>
</author>
<published>2025-07-28T08:22:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5caecea44a7ab069c29cc0d145dcd6a2fd5cf7f'/>
<id>urn:sha1:e5caecea44a7ab069c29cc0d145dcd6a2fd5cf7f</id>
<content type='text'>
commit fec40f44afdabcbc4a7748e4278f30737b54bb1a upstream.

SPI mode doesn't support cmd7, so remove it in mmc_sdio_alive() and
confirm if sdio is active by checking CCCR register value is available
or not.

Signed-off-by: Rex Chen &lt;rex.chen_1@nxp.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250728082230.1037917-2-rex.chen_1@nxp.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier</title>
<updated>2025-07-10T13:57:47+00:00</updated>
<author>
<name>Avri Altman</name>
<email>avri.altman@sandisk.com</email>
</author>
<published>2025-05-26T11:44:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1728e17762b9131f1bbbc3c44964ea32c2f8f866'/>
<id>urn:sha1:1728e17762b9131f1bbbc3c44964ea32c2f8f866</id>
<content type='text'>
[ Upstream commit 009c3a4bc41e855fd76f92727f9fbae4e5917d7f ]

Move the BROKEN_SD_DISCARD quirk for certain SanDisk SD cards from the
`mmc_blk_fixups[]` to `mmc_sd_fixups[]`. This ensures the quirk is
applied earlier in the device initialization process, aligning with the
reasoning in [1]. Applying the quirk sooner prevents the kernel from
incorrectly enabling discard support on affected cards during initial
setup.

[1] https://lore.kernel.org/all/20240820230631.GA436523@sony.com

Fixes: 07d2872bf4c8 ("mmc: core: Add SD card quirk for broken discard")
Signed-off-by: Avri Altman &lt;avri.altman@sandisk.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250526114445.675548-1-avri.altman@sandisk.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Respect quirk_max_rate for non-UHS SDIO card</title>
<updated>2025-03-13T11:50:18+00:00</updated>
<author>
<name>Shawn Lin</name>
<email>shawn.lin@rock-chips.com</email>
</author>
<published>2024-11-22T09:37:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bafaee99fc23834fc666782c5e55f396de44e869'/>
<id>urn:sha1:bafaee99fc23834fc666782c5e55f396de44e869</id>
<content type='text'>
[ Upstream commit a2a44f8da29352f76c99c6904ee652911b8dc7dd ]

The card-quirk was added to limit the clock-rate for a card with UHS-mode
support, although let's respect the quirk for non-UHS mode too, to make the
behaviour consistent.

Signed-off-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Message-ID: &lt;1732268242-72799-1-git-send-email-shawn.lin@rock-chips.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Further prevent card detect during shutdown</title>
<updated>2024-12-14T18:51:34+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2024-11-25T12:24:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=951c53931a91f16fb9ab5d412f0f52dad5562c59'/>
<id>urn:sha1:951c53931a91f16fb9ab5d412f0f52dad5562c59</id>
<content type='text'>
commit 87a0d90fcd31c0f36da0332428c9e1a1e0f97432 upstream.

Disabling card detect from the host's -&gt;shutdown_pre() callback turned out
to not be the complete solution. More precisely, beyond the point when the
mmc_bus-&gt;shutdown() has been called, to gracefully power off the card, we
need to prevent card detect. Otherwise the mmc_rescan work may poll for the
card with a CMD13, to see if it's still alive, which then will fail and
hang as the card has already been powered off.

To fix this problem, let's disable mmc_rescan prior to power off the card
during shutdown.

Reported-by: Anthony Pighin &lt;anthony.pighin@nokia.com&gt;
Fixes: 66c915d09b94 ("mmc: core: Disable card detect during shutdown")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Closes: https://lore.kernel.org/all/BN0PR08MB695133000AF116F04C3A9FFE83212@BN0PR08MB6951.namprd08.prod.outlook.com/
Tested-by: Anthony Pighin &lt;anthony.pighin@nokia.com&gt;
Message-ID: &lt;20241125122446.18684-1-ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: mmc_test: Fix NULL dereference on allocation failure</title>
<updated>2024-09-04T11:23:35+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2024-08-20T08:44:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e40515582141a9e7c84b269be699c05236a499a6'/>
<id>urn:sha1:e40515582141a9e7c84b269be699c05236a499a6</id>
<content type='text'>
[ Upstream commit a1e627af32ed60713941cbfc8075d44cad07f6dd ]

If the "test-&gt;highmem = alloc_pages()" allocation fails then calling
__free_pages(test-&gt;highmem) will result in a NULL dereference.  Also
change the error code to -ENOMEM instead of returning success.

Fixes: 2661081f5ab9 ("mmc_test: highmem tests")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/r/8c90be28-67b4-4b0d-a105-034dc72a0b31@stanley.mountain
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Add mmc_gpiod_set_cd_config() function</title>
<updated>2024-06-16T11:39:57+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2024-04-10T19:16:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee89a7d663da328aa35c5cc853d0e012989d8d49'/>
<id>urn:sha1:ee89a7d663da328aa35c5cc853d0e012989d8d49</id>
<content type='text'>
commit 63a7cd660246aa36af263b85c33ecc6601bf04be upstream.

Some mmc host drivers may need to fixup a card-detection GPIO's config
to e.g. enable the GPIO controllers builtin pull-up resistor on devices
where the firmware description of the GPIO is broken (e.g. GpioInt with
PullNone instead of PullUp in ACPI DSDT).

Since this is the exception rather then the rule adding a config
parameter to mmc_gpiod_request_cd() seems undesirable, so instead
add a new mmc_gpiod_set_cd_config() function. This is simply a wrapper
to call gpiod_set_config() on the card-detect GPIO acquired through
mmc_gpiod_request_cd().

Reviewed-by: Andy Shevchenko &lt;andy@kernel.org&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240410191639.526324-2-hdegoede@redhat.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Do not force a retune before RPMB switch</title>
<updated>2024-06-16T11:39:53+00:00</updated>
<author>
<name>Jorge Ramirez-Ortiz</name>
<email>jorge@foundries.io</email>
</author>
<published>2024-01-03T11:29:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e345538cbc2f5141022aaaedee22a8e1486e35a0'/>
<id>urn:sha1:e345538cbc2f5141022aaaedee22a8e1486e35a0</id>
<content type='text'>
commit 67380251e8bbd3302c64fea07f95c31971b91c22 upstream.

Requesting a retune before switching to the RPMB partition has been
observed to cause CRC errors on the RPMB reads (-EILSEQ).

Since RPMB reads can not be retried, the clients would be directly
affected by the errors.

This commit disables the retune request prior to switching to the RPMB
partition: mmc_retune_pause() no longer triggers a retune before the
pause period begins.

This was verified with the sdhci-of-arasan driver (ZynqMP) configured
for HS200 using two separate eMMC cards (DG4064 and 064GB2). In both
cases, the error was easy to reproduce triggering every few tenths of
reads.

With this commit, systems that were utilizing OP-TEE to access RPMB
variables will experience an enhanced performance. Specifically, when
OP-TEE is configured to employ RPMB as a secure storage solution, it not
only writes the data but also the secure filesystem within the
partition. As a result, retrieving any variable involves multiple RPMB
reads, typically around five.

For context, on ZynqMP, each retune request consumed approximately
8ms. Consequently, reading any RPMB variable used to take at the very
minimum 40ms.

After droping the need to retune before switching to the RPMB partition,
this is no longer the case.

Signed-off-by: Jorge Ramirez-Ortiz &lt;jorge@foundries.io&gt;
Acked-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20240103112911.2954632-1-jorge@foundries.io
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Avoid negative index with array access</title>
<updated>2024-04-10T14:19:31+00:00</updated>
<author>
<name>Mikko Rapeli</name>
<email>mikko.rapeli@linaro.org</email>
</author>
<published>2024-03-13T13:37:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=81b8645feca08a54c7c4bf36e7b176f4983b2f28'/>
<id>urn:sha1:81b8645feca08a54c7c4bf36e7b176f4983b2f28</id>
<content type='text'>
commit cf55a7acd1ed38afe43bba1c8a0935b51d1dc014 upstream.

Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns
prev_idata = idatas[i - 1], but doesn't check that the iterator i is
greater than zero. Let's fix this by adding a check.

Fixes: 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu")
Link: https://lore.kernel.org/all/20231129092535.3278-1-avri.altman@wdc.com/
Cc: stable@vger.kernel.org
Signed-off-by: Mikko Rapeli &lt;mikko.rapeli@linaro.org&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Tested-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Link: https://lore.kernel.org/r/20240313133744.2405325-2-mikko.rapeli@linaro.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
