RFC mmc: rtsx_usb_sdmmc: qualify card-detect on tray readers

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