Hi, this is your Linux kernel regression tracker speaking.
On 06.12.21 17:10, Manivannan Sadhasivam wrote:
From: Loic Poulain loic.poulain@linaro.org
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@vger.kernel.org #5.13 Fixes: 020d3b26c07a ("bus: mhi: Early MHI resume failure in non M3 state") Reported-by: Kalle Valo kvalo@codeaurora.org Reported-by: Pengyu Ma mapengyu@gmail.com
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@codeaurora.org/
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@codeaurora.org/