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

[Sean Rhodes <sean@starlabs.systems>]

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?
  - is an rts5139-style qualification acceptable in rtsx_usb_sdmmc if it is
    kept out of the generic MMC core?
  - or should the USB/cardreader parent expose a qualified media-present
    state to the SD/MMC child?

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(-)