Hi, this is your Linux kernel regression tracker speaking. On 06.12.21 17:10, Manivannan Sadhasivam wrote: > From: Loic Poulain <loic.poulain@xxxxxxxxxx> > > For whatever reason, some devices like QCA6390, WCN6855 using ath11k > are not in M3 state during PM resume, but still functional. The > mhi_pm_resume should then not fail in those cases, and let the higher > level device specific stack continue resuming process. > > Add a new parameter to mhi_pm_resume, to force resuming, whatever the > current MHI state is. This fixes a regression with non functional > ath11k WiFi after suspend/resume cycle on some machines. > > Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214179 > > Cc: stable@xxxxxxxxxxxxxxx #5.13 > Fixes: 020d3b26c07a ("bus: mhi: Early MHI resume failure in non M3 state") > Reported-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx> > Reported-by: Pengyu Ma <mapengyu@xxxxxxxxx> FWIW: In case you need to send an improved patch, could you please add this before the 'Reported-by:' (see (¹) below for the reasoning): Link: https://lore.kernel.org/regressions/871r5p0x2u.fsf@xxxxxxxxxxxxxx/ And if the patch is already good to go: could the subsystem maintainer please add it when applying? See(¹) for the reasoning. Thx. Ciao, Thorsten, your Linux kernel regression tracker. (¹) Long story: The commit message would benefit from a link to the regression report on the mailing list, for reasons explained in Documentation/process/submitting-patches.rst. To quote: ``` If related discussions or any other background information behind the change can be found on the web, add 'Link:' tags pointing to it. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; ``` This concept is old, but the text was reworked recently to make this use case for the Link: tag clearer. For details see: https://git.kernel.org/linus/1f57bd42b77c Yes, that "Link:" is not really crucial; but it's good to have if someone needs to look into the backstory of this change sometime in the future. But I care for a different reason. I'm tracking this regression (and others) with regzbot, my Linux kernel regression tracking bot. This bot will notice if a patch with a Link: tag to a tracked regression gets posted and record that, which allowed anyone looking into the regression to quickly gasp the current status from regzbot's webui (https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The bot will also notice if a commit with a Link: tag to a regression report is applied by Linus and then automatically mark the regression as resolved then. IOW: this tag makes my life a regression tracker a lot easier, as I otherwise have to tell regzbot manually when the fix lands. :-/ P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression. #regzbot ^backmonitor: https://lore.kernel.org/regressions/871r5p0x2u.fsf@xxxxxxxxxxxxxx/
