[PATCH 0/2] mmc: core: sdio: fix UHS init with fixed 1.8V vqmmc

[PATCH 0/2] mmc: core: sdio: fix UHS init with fixed 1.8V vqmmc

[Deomid rojer Ryabkov]

The Realtek RTL8822CS SDIO Wi-Fi module on the FriendlyElec NanoPi R2S
Plus (fixed 1.8V vqmmc) reports S18A = 1 in its R4 response although the
bus is already at 1.8V, contrary to the SDIO Simplified Specification
3.00, section 3.1.2. CMD11 then times out and the module ends up at
50 MHz high-speed instead of SDR104.

Patch 1 makes SDIO init fall back to high-speed mode if UHS init fails
(e.g. tuning), instead of failing the card altogether.

Patch 2 fixes the RTL8822CS case. There are two ways to do it, and I'd
like your preference:

  2/2      skips CMD11 when the host is already at 1.8V. Simple and per
           spec, but a non-compliant card that needs CMD11 anyway would
           drop to high-speed mode (it keeps working thanks to patch 1).

  2/2 alt  (sent as a reply to 2/2) keeps sending CMD11 and only retries
           without it if it fails while still at 1.8V. No change for any
           card that works today; costs ~0.85s of boot time on affected
           boards.

Tested on a NanoPi R2S Plus (OpenWrt 25.12, Linux 6.12.112 with these
patches; applies to mainline as of 2026-10-22): both variants reach
SDR104 at 150 MHz; iperf as a 5 GHz VHT80 station goes from 70/29 to
123/125 Mbit/s (rx/tx). eMMC (HS200) and SD card on the same SoC are
unaffected.

The device tree part for the R2S Plus is sent separately to
linux-rockchip.

Deomid rojer Ryabkov (2):
  mmc: core: sdio: retry without UHS if UHS init fails
  mmc: core: sdio: skip CMD11 if signalling is already 1.8V

 drivers/mmc/core/sdio.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

-- 
2.53.0

[PATCH 1/2] mmc: core: sdio: retry without UHS if UHS init fails

[Deomid rojer Ryabkov]

If mmc_sdio_init_uhs_card() fails, typically because tuning finds no
working sample phase, card initialisation fails and the card is not
usable at all, even though it would work fine in high-speed mode.

This happens for example on the FriendlyElec NanoPi R2S Plus when the
SDIO pins of the RTL8822CS Wi-Fi module are left at their default 4 mA
drive strength:

  dwmmc_rockchip ff5f0000.mmc: All phases bad!
  mmc2: tuning execution failed: -5
  mmc2: error -5 whilst initialising SDIO card
  [... repeated for every init frequency ...]
  mmc2: Failed to initialize a non-removable card

There is already a fallback for a failure to read the CCCR in UHS mode:
power-cycle the card and restart the init sequence without
R4_18V_PRESENT. Do the same when UHS init fails, so that the card comes
up in high-speed mode instead:

  mmc2: UHS init failed (-5), retrying without UHS
  mmc2: Skipping voltage switch
  mmc2: new high speed SDIO card at address 0001

The fallback is taken at most once, as the retry doesn't request UHS.

Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
---
 drivers/mmc/core/sdio.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 83085e7648..6787fdf1c5 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -867,8 +867,14 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	/* Only if card supports 1.8v and UHS signaling */
 	if ((ocr & R4_18V_PRESENT) && card->sw_caps.sd3_bus_mode) {
 		err = mmc_sdio_init_uhs_card(card);
-		if (err)
-			goto remove;
+		if (err) {
+			pr_warn("%s: UHS init failed (%d), retrying without UHS\n",
+				mmc_hostname(host), err);
+			mmc_sdio_pre_init(host, ocr_card,
+					  card != oldcard ? card : NULL);
+			retries = 0;
+			goto try_again;
+		}
 	} else {
 		/*
 		 * Switch to high-speed (if supported).
-- 
2.53.0

[PATCH 2/2] mmc: core: sdio: skip CMD11 if signalling is already 1.8V

[Deomid rojer Ryabkov]

Per the SDIO Simplified Specification Version 3.00, section 3.1.2, a card
whose signalling is already at 1.8V must report S18A = 0 in the R4
response, and the core relies on that: it only sends CMD11
(SD_SWITCH_VOLTAGE) when S18A is set.

Some cards don't follow this. The Realtek RTL8822CS (as fitted on the
FriendlyElec NanoPi R2S Plus, where the M.2 SDIO bus is wired to a fixed
1.8V vqmmc) answers CMD5 with S18A = 1 even though the bus is already at
1.8V. CMD11 then times out:

  dwmmc_rockchip ff5f0000.mmc: Unexpected CMD11 timeout
  mmc_host mmc2: Timeout sending command (cmd 0x10202000 arg 0x0 status 0x90202000)
  mmc2: new high speed SDIO card at address 0001

and the card ends up in 50 MHz high-speed mode instead of SDR104.

When vqmmc can't do 3.3V, mmc_set_initial_signal_voltage() has already
fallen back to 1.8V by the time CMD5 is sent, so the host knows there is
nothing to switch. Skip CMD11 in that case. ocr keeps R4_18V_PRESENT, so
mmc_sdio_init_uhs_card() still runs and the card is tuned to SDR104:

  dwmmc_rockchip ff5f0000.mmc: Successfully tuned phase to 64
  mmc2: new ultra high speed SDR104 SDIO card at address 0001

Hosts that start at 3.3V are not affected, nor are compliant cards that
report S18A = 0 at 1.8V. A non-compliant card that does need CMD11
before entering UHS at 1.8V would now fail UHS init; with the previous
patch it falls back to high-speed mode and keeps working.

FriendlyElec's BSP for this board works around this with a card
quirk, MMC_QUIRK_BROKEN_ROCR_S18A[1], matched on the "realtek,rtl8822cs"
compatible, which drops the switch request whenever this chip is
present. The misreported S18A is the card's fault, but ignoring it is
only correct when the bus is already at 1.8V: on a board with a
switchable vqmmc the same chip would then be run in UHS at 3.3V. A card
quirk would need knowledge of the board's supply that it doesn't have.
The core does know the current signal voltage, so handle it there, which
also takes care of any other card that turns out to behave the same way.

[1] https://github.com/friendlyarm/kernel-rockchip/commit/aee62cf7ae16b5ede6c6d92a8ee20e796482754e
Cc: Jensen Huang <jensenhuang@friendlyarm.com>
Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
---
 drivers/mmc/core/sdio.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 6787fdf1c5..a986ee04ba 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -737,9 +737,11 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	 * 1.8v, the card sets S18A to 0 in the R4 response. So it will
 	 * fails to check rocr & R4_18V_PRESENT,  but we still need to
 	 * try to init uhs card. sdio_read_cccr will take over this task
-	 * to make sure which speed mode should work.
+	 * to make sure which speed mode should work. Some cards (RTL8822CS)
+	 * set S18A regardless, so don't send CMD11 if we are already at 1.8V.
 	 */
-	if (rocr & ocr & R4_18V_PRESENT) {
+	if ((rocr & ocr & R4_18V_PRESENT) &&
+	    host->ios.signal_voltage != MMC_SIGNAL_VOLTAGE_180) {
 		err = mmc_set_uhs_voltage(host, ocr_card);
 		if (err == -EAGAIN) {
 			mmc_sdio_pre_init(host, ocr_card, card);
-- 
2.53.0

[PATCH 2/2 alt] mmc: core: sdio: retry without CMD11 if it fails at 1.8V

[Deomid rojer Ryabkov]

Per the SDIO Simplified Specification Version 3.00, section 3.1.2, a card
whose signalling is already at 1.8V must report S18A = 0 in the R4
response, and the core relies on that: it only sends CMD11
(SD_SWITCH_VOLTAGE) when S18A is set.

Some cards don't follow this. The Realtek RTL8822CS (as fitted on the
FriendlyElec NanoPi R2S Plus, where the M.2 SDIO bus is wired to a fixed
1.8V vqmmc) answers CMD5 with S18A = 1 even though the bus is already at
1.8V. CMD11 then times out, the core drops R4_18V_PRESENT and the card
ends up in 50 MHz high-speed mode instead of SDR104.

Keep sending CMD11 as before, but if it fails and the signalling is
still at 1.8V after the power cycle (i.e. vqmmc can't do 3.3V), there was
nothing to switch: power-cycle and retry init once without CMD11, keeping
R4_18V_PRESENT so that UHS init runs:

  dwmmc_rockchip ff5f0000.mmc: Unexpected CMD11 timeout
  mmc_host mmc2: Timeout sending command (cmd 0x10202000 arg 0x0 status 0x90202000)
  mmc2: CMD11 failed at 1.8V, retrying without it
  dwmmc_rockchip ff5f0000.mmc: Successfully tuned phase to 66
  mmc2: new ultra high speed SDR104 SDIO card at address 0001

Cards that handle CMD11 today, compliant or not, are not affected, nor
are hosts that can switch to 3.3V, as they are back at 3.3V after the
power cycle. The cost is the failed CMD11 on affected boards: on the
R2S Plus the card comes up about 0.85s later than when CMD11 is skipped
outright (1.65-1.71s vs. 0.82-0.83s after boot).

FriendlyElec's BSP for this board works around this with a card
quirk, MMC_QUIRK_BROKEN_ROCR_S18A[1], matched on the "realtek,rtl8822cs"
compatible, which drops the switch request whenever this chip is
present. The misreported S18A is the card's fault, but ignoring it is
only correct when the bus is already at 1.8V: on a board with a
switchable vqmmc the same chip would then be run in UHS at 3.3V. A card
quirk would need knowledge of the board's supply that it doesn't have.
The core can tell from a failed CMD11 at 1.8V that there was nothing to
switch, so handle it there, which also takes care of any other card that
turns out to behave the same way.

[1] https://github.com/friendlyarm/kernel-rockchip/commit/aee62cf7ae16b5ede6c6d92a8ee20e796482754e
Cc: Jensen Huang <jensenhuang@friendlyarm.com>
Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
---
This is an alternative to patch 2/2 ("mmc: core: sdio: skip CMD11 if
signalling is already 1.8V"); apply one or the other. 2/2 follows the
spec and skips CMD11; this one keeps sending it and only retries without
it if it fails at 1.8V, at the cost of ~0.85s on affected boards.

 drivers/mmc/core/sdio.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 6787fdf1c5..0a96469fd4 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -665,6 +665,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	int retries = 10;
 	u32 rocr = 0;
 	u32 ocr_card = ocr;
+	bool skip_cmd11 = false;
 
 	WARN_ON(!host->claimed);
 
@@ -737,14 +738,23 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	 * 1.8v, the card sets S18A to 0 in the R4 response. So it will
 	 * fails to check rocr & R4_18V_PRESENT,  but we still need to
 	 * try to init uhs card. sdio_read_cccr will take over this task
-	 * to make sure which speed mode should work.
+	 * to make sure which speed mode should work. Some cards (RTL8822CS)
+	 * set S18A regardless and then fail CMD11; if that happens at 1.8V,
+	 * retry without it.
 	 */
-	if (rocr & ocr & R4_18V_PRESENT) {
+	if ((rocr & ocr & R4_18V_PRESENT) && !skip_cmd11) {
 		err = mmc_set_uhs_voltage(host, ocr_card);
 		if (err == -EAGAIN) {
 			mmc_sdio_pre_init(host, ocr_card, card);
 			retries--;
 			goto try_again;
+		} else if (err &&
+			   host->ios.signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+			pr_warn("%s: CMD11 failed at 1.8V, retrying without it\n",
+				mmc_hostname(host));
+			skip_cmd11 = true;
+			mmc_sdio_pre_init(host, ocr_card, card);
+			goto try_again;
 		} else if (err) {
 			ocr &= ~R4_18V_PRESENT;
 		}
-- 
2.53.0

Re: [PATCH 2/2] mmc: core: sdio: skip CMD11 if signalling is already 1.8V

[Shawn Lin]

在 2026/10/24 星期六 7:28, Deomid rojer Ryabkov 写道:
> Per the SDIO Simplified Specification Version 3.00, section 3.1.2, a card
> whose signalling is already at 1.8V must report S18A = 0 in the R4
> response, and the core relies on that: it only sends CMD11
> (SD_SWITCH_VOLTAGE) when S18A is set.
> 
> Some cards don't follow this. The Realtek RTL8822CS (as fitted on the
> FriendlyElec NanoPi R2S Plus, where the M.2 SDIO bus is wired to a fixed
> 1.8V vqmmc) answers CMD5 with S18A = 1 even though the bus is already at
> 1.8V. CMD11 then times out:
> 
>    dwmmc_rockchip ff5f0000.mmc: Unexpected CMD11 timeout
>    mmc_host mmc2: Timeout sending command (cmd 0x10202000 arg 0x0 status 0x90202000)
>    mmc2: new high speed SDIO card at address 0001
> 
> and the card ends up in 50 MHz high-speed mode instead of SDR104.
> 
> When vqmmc can't do 3.3V, mmc_set_initial_signal_voltage() has already
> fallen back to 1.8V by the time CMD5 is sent, so the host knows there is
> nothing to switch. Skip CMD11 in that case. ocr keeps R4_18V_PRESENT, so
> mmc_sdio_init_uhs_card() still runs and the card is tuned to SDR104:
> 
>    dwmmc_rockchip ff5f0000.mmc: Successfully tuned phase to 64
>    mmc2: new ultra high speed SDR104 SDIO card at address 0001
> 
> Hosts that start at 3.3V are not affected, nor are compliant cards that
> report S18A = 0 at 1.8V. A non-compliant card that does need CMD11
> before entering UHS at 1.8V would now fail UHS init; with the previous
> patch it falls back to high-speed mode and keeps working.
> 
> FriendlyElec's BSP for this board works around this with a card
> quirk, MMC_QUIRK_BROKEN_ROCR_S18A[1], matched on the "realtek,rtl8822cs"
> compatible, which drops the switch request whenever this chip is


Thanks for this series.

I knew some vendor's SDIO cards misbehave it on Rockchip's bug trace
system, including this one. This patch matches what I suggested there
instead of the alternative one. FWIW,

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> present. The misreported S18A is the card's fault, but ignoring it is
> only correct when the bus is already at 1.8V: on a board with a
> switchable vqmmc the same chip would then be run in UHS at 3.3V. A card
> quirk would need knowledge of the board's supply that it doesn't have.
> The core does know the current signal voltage, so handle it there, which
> also takes care of any other card that turns out to behave the same way.
> 
> [1] https://github.com/friendlyarm/kernel-rockchip/commit/aee62cf7ae16b5ede6c6d92a8ee20e796482754e
> Cc: Jensen Huang <jensenhuang@friendlyarm.com>
> Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
> ---
>   drivers/mmc/core/sdio.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 6787fdf1c5..a986ee04ba 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -737,9 +737,11 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
>   	 * 1.8v, the card sets S18A to 0 in the R4 response. So it will
>   	 * fails to check rocr & R4_18V_PRESENT,  but we still need to
>   	 * try to init uhs card. sdio_read_cccr will take over this task
> -	 * to make sure which speed mode should work.
> +	 * to make sure which speed mode should work. Some cards (RTL8822CS)
> +	 * set S18A regardless, so don't send CMD11 if we are already at 1.8V.
>   	 */
> -	if (rocr & ocr & R4_18V_PRESENT) {
> +	if ((rocr & ocr & R4_18V_PRESENT) &&
> +	    host->ios.signal_voltage != MMC_SIGNAL_VOLTAGE_180) {
>   		err = mmc_set_uhs_voltage(host, ocr_card);
>   		if (err == -EAGAIN) {
>   			mmc_sdio_pre_init(host, ocr_card, card);