RE: mmc0: error -95 doing runtime resume

[Ricky WU <ricky_wu@realtek.com>]

> + Ricky
> 
> On Fri, 21 Feb 2025 at 18:20, Bart Van Assche <bvanassche@acm.org> wrote:
> >
> >
> > On 2/21/25 7:41 AM, Thomas Haschka wrote:
> > > Bug Fix: block: Improve stability of SD cards in Microsoft Surface GO 2 and
> > >               possibly other devices.
> > >
> > >
> > > The commit 65a558f66c308
> > >      block: Improve performance for BLK_MQ_F_BLOCKING drivers
> > >
> > > basically made the use of SD cards in my Microsoft Surface GO 2
> impossible.
> > > The cards do stop functioning after about 15 minutes. Mostly at io
> > > intensive tasks.
> > >
> > > As outlined in https://bugzilla.kernel.org/show_bug.cgi?id=218821
> > > i bisected the problem that yielded an unstable operation of the
> > > cardreader on my Surface GO 2.
> > > I successfully reversed the commit 65a558f66c308 in 6.12.16 using
> > > the attached patch. As I suppose the bug introduced with this commit
> > > might hit other users of sd-cards in similar hardware I suggest this
> > > commit shall be reversed, even if the improved performance might be
> gone.
> >
> > Thank you for having bisected this issue and for having shared the
> > result of the bisection process. This is very useful information.
> >
> > Since the commit mentioned above is about 1.5 years old and has not
> > caused any issues for anyone who is not using an SD card reader, that
> > commit is probably not the root cause of the reported behavior. Are SD
> > cards controlled by the MMC driver? If so, I think the next step is to
> > take a close look at the MMC driver. I have Cc-ed the MMC driver
> maintainer.
> 
> There was another thread [1] where I tried to loop in Ricky Wu, but there was
> no response. I have added him to this tread too.
> 
Hi Ulf,
Because I was waiting for the result that revert 101bd907b424 ("misc: rtsx: judge ASPM Mode to set PETXCFG Reg")
Can fix this issue or not, but I did not see any response...

Hi Thomas,
This issue(this mail thread) and [1] are the same issue?
And this issue only can reproduce on surface go 2?
If so, I need to find correct platform to reproduce this issue on my hand


> For the record, I agree, even if reverting 65a558f66c308 solves the issue, it's
> not the correct fix.
> 
> Unless we can get some help from Ricky, we can try to drop assigning
> "MMC_CAP_AGGRESSIVE_PM" in realtek_init_host() to see if that solves the
> problem. Or if debugfs is enabled, we can disable
> MMC_CAP_AGGRESSIVE_PM for the mmc host via the "caps" debugfs-node.
> 
> Thomas can you try to drop MMC_CAP_AGGRESSIVE_PM and see if that solves
> the problem?
> 
> Kind regards
> Uffe
> 
> [1]
> https://lore.kernel.org/all/CAPDyKFq4-fL3oHeT9phThWQJqzicKeA447WBJUbtc
> KPhdZ2d1A@mail.gmail.com/