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

[Michal Pecio <michal.pecio@gmail.com>]

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