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 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?

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

Kind regards
Uffe