Re: [PATCH v2 1/2] misc: rtsx_usb: avoid USB I/O in runtime autosuspend

[Sean Rhodes]

> How is the driver supposed to detect card insertion after the last poll
but before the reader goes to suspend and can issue remote wakeup?

The reader uses remote wake; what hardware are you testing on?

On Mon, 5 Oct 2026 at 09:30, Michal Pecio <michal.pecio@xxxxxxxxx> wrote:
>
> On Mon,  6 Jul 2026 16:40:43 +0100, Sean Rhodes wrote:
> > The runtime autosuspend callback currently queries card status and
> > clears OCP by issuing USB register accesses. This can run from the
> > USB runtime-PM path itself, which is the wrong place to start more
> > device I/O.
> >
> > Keep a cached copy of the card-status bits from normal status reads
> > instead. During runtime autosuspend, use that cached value only to
> > preserve the existing Memory Stick autosuspend deferral.
>
> How is the driver supposed to detect card insertion after the last poll
> but before the reader goes to suspend and can issue remote wakeup?
>
> This is exactly what happens now: if I insert a new card within two
> seconds of the "card removed" message showing up (which itself happens
> up to a second after removal) the insertion is never detected and the
> reader enters suspend with the card in.
>
> It seems that not only was "starting more I/O in the runtime-PM path"
> actually a good idea, but polling should only stop when the parent USB
> device suspends, not the child MMC host, because there is a two second
> delay between them. And even with this patch reverted, insertion never
> works if USB autosuspend is simply disabled altogether.
>
> Also, does anyone know if there is any way to utilize the interrupt
> endpoint instead of polling? I tried submitting a URB to it and got
> regular responses, but only zeros. Can this be changed?
>
> > Do not treat raw SD_CD as an autosuspend blocker, because tray-based
> > SD readers can assert SD_CD with an empty tray. A real SD card is
> > protected by the SD/MMC child runtime-PM usage once powered.
>
> Sounds like the proper condition is to ignore the card if and only if
> it failed to initialize and has not been swapped for a new one.
>
> Hence the question about interrupts: this would vastly reduce the risk
> that a swap for an actual working card remains undetected.
>
> Regards,
> Michal