From: Ricky WU <ricky_wu@realtek.com>
To: Matthew Schwartz <matthew.schwartz@linux.dev>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function
Date: Thu, 15 Jan 2026 10:23:16 +0000 [thread overview]
Message-ID: <220bd61b3ab743b492632764a38f95f0@realtek.com> (raw)
In-Reply-To: <20251229204526.2850803-1-matthew.schwartz@linux.dev>
Hi Matthew,
Thanks for working on this patch.
We’ve tested this change on our platforms and can confirm that adding the
card_busy() callback does resolve the
“cannot verify signal voltage switch” issue for us 👍.
That said, while reviewing the change we noticed a potential redundancy in
the existing driver logic. In sdmmc_switch_voltage() we already perform
explicit DAT line stabilization checks via
sd_wait_voltage_stable_1() and sd_wait_voltage_stable_2().
Once card_busy() is implemented and used by the MMC core during the
voltage-switch verification phase, these two stabilization steps appear to
be partially overlapping with what the core now validates via
card_busy(). In our testing, with card_busy() present, the stable_1 /
stable_2 logic no longer seems strictly necessary and could likely be
simplified or removed with some adjustment.
From a process point of view, we’re not sure which approach you’d prefer:
Land your patch as-is first, and then we can follow up with a separate
cleanup/modification patch to adjust sdmmc_switch_voltage(), or
We can prepare an additional patch that builds on top of yours and share
it with you for review, so the changes can be aligned together.
Please let us know which option you think makes more sense for upstream, or
if you’d prefer a different approach.
Thanks again for the fix and for looking into this driver.
Best regards,
Ricky
> rtsx_pci_sdmmc does not have an sdmmc_card_busy function, so any voltage
> switches cause a kernel warning, "mmc0: cannot verify signal voltage switch."
>
> Copy the sdmmc_card_busy function from rtsx_pci_usb to rtsx_pci_sdmmc to
> fix this.
>
> Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> ---
> drivers/mmc/host/rtsx_pci_sdmmc.c | 41
> +++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
> b/drivers/mmc/host/rtsx_pci_sdmmc.c
> index dc2587ff8519..4db3328f46df 100644
> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> @@ -1306,6 +1306,46 @@ static int sdmmc_switch_voltage(struct mmc_host
> *mmc, struct mmc_ios *ios)
> return err;
> }
>
> +static int sdmmc_card_busy(struct mmc_host *mmc) {
> + struct realtek_pci_sdmmc *host = mmc_priv(mmc);
> + struct rtsx_pcr *pcr = host->pcr;
> + int err;
> + u8 stat;
> + u8 mask = SD_DAT3_STATUS | SD_DAT2_STATUS | SD_DAT1_STATUS
> + | SD_DAT0_STATUS;
> +
> + mutex_lock(&pcr->pcr_mutex);
> +
> + rtsx_pci_start_run(pcr);
> +
> + err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
> + SD_CLK_TOGGLE_EN |
> SD_CLK_FORCE_STOP,
> + SD_CLK_TOGGLE_EN);
> + if (err)
> + goto out;
> +
> + mdelay(1);
> +
> + err = rtsx_pci_read_register(pcr, SD_BUS_STAT, &stat);
> + if (err)
> + goto out;
> +
> + err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
> + SD_CLK_TOGGLE_EN |
> +SD_CLK_FORCE_STOP, 0);
> +out:
> + mutex_unlock(&pcr->pcr_mutex);
> +
> + if (err)
> + return err;
> +
> + /* check if any pin between dat[0:3] is low */
> + if ((stat & mask) != mask)
> + return 1;
> + else
> + return 0;
> +}
> +
> static int sdmmc_execute_tuning(struct mmc_host *mmc, u32 opcode) {
> struct realtek_pci_sdmmc *host = mmc_priv(mmc); @@ -1418,6
> +1458,7 @@ static const struct mmc_host_ops realtek_pci_sdmmc_ops = {
> .get_ro = sdmmc_get_ro,
> .get_cd = sdmmc_get_cd,
> .start_signal_voltage_switch = sdmmc_switch_voltage,
> + .card_busy = sdmmc_card_busy,
> .execute_tuning = sdmmc_execute_tuning,
> .init_sd_express = sdmmc_init_sd_express, };
> --
> 2.52.0
next prev parent reply other threads:[~2026-01-15 10:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 20:45 Matthew Schwartz
2026-01-15 10:23 ` Ricky WU [this message]
2026-01-16 17:24 ` Matthew Schwartz
2026-01-21 14:54 ` Ulf Hansson
2026-01-22 8:47 ` Ricky WU
2026-01-28 3:06 ` Ricky WU
2026-01-28 12:42 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=220bd61b3ab743b492632764a38f95f0@realtek.com \
--to=ricky_wu@realtek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=matthew.schwartz@linux.dev \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®