Re: [RFC PATCH 0/2] mmc: rtsx_usb_sdmmc: qualify card-detect on tray readers

[Ulf Hansson]

On Wed, May 13, 2026 at 1:40 PM Sean Rhodes <sean@starlabs.systems> wrote:
>
> Hi Uffe, USB/cardreader folks,
>
> Uffe suggested sending this as an RFC and adding the USB/cardreader side,
> because this may need input on where the media qualification should live.
>
> I previously sent an RFC for the USB/cardreader runtime-PM side of this
> problem. That did not get USB/cardreader-side guidance on the detect
> layering question; the only substantive feedback was that the MMC child
> should already own runtime PM for a real inserted card. I have since
> retested that, and it is correct: with real media inserted,
> rtsx_usb_sdmmc holds runtime_usage=1 and the USB parent remains active
> through runtime_active_kids=1.
>
> The remaining failure is narrower: empty tray only. Raw SD_CD remains
> asserted, the MMC core repeatedly probes non-existent media, and the
> runtime-PM hierarchy does not settle.
>
> This is an RFC for the Realtek RTS5129 tray-reader false-detect issue.
>
> Short version: on these machines, raw SD_CD is not a reliable "card is
> present" signal. It is asserted when the tray is inserted, even if the tray
> contains no SD card.
>
> That means the current driver reports card-present to the MMC core for an
> empty tray. The MMC core then does what it should do: it tries to initialize
> a card. The commands time out, no mmcblk device is created, but because
> SD_CD remains asserted the detect path is entered again. In practice this
> keeps rtsx_usb_sdmmc runtime-active and prevents the USB parent from
> autosuspending.
>
> I retested this on an RTS5129 reader:
>
>   - tray removed: no mmcblk device, rtsx_usb_sdmmc suspends, USB parent
>     suspends
>   - empty tray inserted: no mmcblk device, repeated CMD0/CMD8/CMD55/CMD1
>     probe loop, rtsx_usb_sdmmc remains active, USB parent remains active
>   - tray + SD card: mmcblk0 appears and reads correctly; the MMC child
>     holds runtime PM as expected
>
> The old Realtek rts5139 staging driver did not treat raw tray/CD state as
> sufficient. It qualified insertion by checking whether media actually
> responded before reporting a card present. That approach works on this
> hardware, and avoids papering over the issue in runtime PM.
>
> I know the previous version put the validation directly in ->get_cd(), and
> the objection was that MMC command probing does not belong there. I'm not
> trying to ignore that feedback. The question for this RFC is the layering:
>
>   - if the only exposed hardware bit is "tray inserted", not "card present",
>     where should the Realtek-specific media qualification live?

It depends on what the media qualification must consist of.

>   - is an rts5139-style qualification acceptable in rtsx_usb_sdmmc if it is
>     kept out of the generic MMC core?

We can certainly add some specific hacks to the rtsx_usb_sdmmc for
this, but I think we should be able to do it without having to
build/send all the corresponding mmc commands directly in the driver.
In principle we should be able to rely on the mmc_rescan() work to do
this for us, in one way or the other.

A part that is still a bit unclear to me, is how we should handle the
card detect when the tray is/gets inserted. Is it possible to
insert/remove a card to the tray when the tray is already inserted -
or does the tray need to be removed (and inserted again) to allow
this?

>   - or should the USB/cardreader parent expose a qualified media-present
>     state to the SD/MMC child?

Is there a way for the USB card reader driver to figure out if there
is a "card present"?

I thought all it could do was to signal whether the tray is inserted or not? No?

>
> This is intentionally copied to linux-usb and the char/misc/cardreader
> maintainers, not just linux-mmc, because one possible answer is that the
> USB/cardreader parent should expose a qualified media-present state rather
> than having rtsx_usb_sdmmc compensate for raw SD_CD.
>
> Patch 2 keeps the validation path in a known initial electrical state by
> starting SD power-up at 3.3V, matching the old Realtek rts5139 driver. It is
> included because the validation sequence must not inherit a previous 1.8V
> state.
>
> I have deliberately left the SDR/UHS rate patches out of this RFC. They are
> separate capability work and just make this harder to review. This series is
> only about making tray card-detect correct and stopping the empty-tray detect
> loop.
>
> Thanks,
> Sean
>
> Sean Rhodes (2):
>   mmc: rtsx_usb_sdmmc: avoid false card-detect on tray readers
>   mmc: rtsx_usb_sdmmc: start card power-up at 3.3V
>
>  drivers/mmc/host/rtsx_usb_sdmmc.c | 161 ++++++++++++++++++++++++++++--
>  1 file changed, 153 insertions(+), 8 deletions(-)

Kind regards
Uffe