Re: [PATCH v2 RESEND 1/6] mmc: rtsx_usb_sdmmc: avoid false card-detect on tray readers

[Ulf Hansson]

On Tue, 24 Mar 2026 at 14:14, Sean Rhodes <sean@starlabs.systems> wrote:
>
> On Tue, 24 Mar 2026 at 12:58, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> >
> > On Tue, 24 Mar 2026 at 13:30, Sean Rhodes <sean@starlabs.systems> wrote:
> > >
> > > On Tue, 24 Mar 2026 at 12:23, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > > >
> > > > On Tue, 24 Mar 2026 at 12:59, Sean Rhodes <sean@starlabs.systems> wrote:
> > > > >
> > > > > Hi Uffe
> > > > >
> > > > > Thanks for the feedback - to answer your questions:
> > > > >
> > > > > > Would you mind elaborating on this so I can better understand the problem?
> > > > >
> > > > > SD_CD is used for presence, but that's asserted by trays or blanking cards.
> > > > >
> > > > > > What prevents the MMC core from handling this correctly?
> > > > > >
> > > > > > Don't some of the commands time out, eventually causing mmc_rescan() to bail out?
> > > > >
> > > > > It does bail out, but SD_CD is still asserted, so it tries again. The
> > > > > main thing this breaks is S3 entry - it's either slow (like 100
> > > > > seconds), or never gets there.
> > > >
> > > > First, please don't top post, but reply in-line below so we can follow
> > > > the discussion.
> > > >
> > > > It's the mmc driver's ->runtime_resume() callback that calls
> > > > mmc_detect_change(host->mmc, 0).
> > > >
> > > > It's sounds to me like the mmc host is being runtime resumed/suspended
> > > > over and over again, hence we end up calling mmc_detect_change() many
> > > > times when it's not really needed. Right?
> > > >
> > >
> > > Correct
> >
> > So why does the rtsx usb card driver do that?
>
> I don't know; I'd assume it was just a shortcut or done by people who
> didn't have the hardware when moving the driver out of staging (see
> 00d8521dcd236d1b8f664f54a0309e96bfdcb4f9 which works flawlessly)
>
> >
> > Could it keep the mmc host runtime resumed for a while and then we
> > could add a debounce period to the call to mmc_detect_change()?
>
> I might be missing something, but wouldn't that just make symptoms
> less obvious? We have bad detection - why not fix that?
>

I don't think so. Assuming the host gets runtime resumed at some point
again, after we failed to detect a card. Not sure if this solves the
problem, but should just make things less noisy, I think.

Anyway, you may very well be right, but I don't know how to fix this
properly on the usb side.

That said, we might need input from the usb maintainers on how to
proceed. Perhaps if you make a new submission (RFC), by describing the
problem in more detail and ask for guidance from the usb folkz?

Kind regards
Uffe