On 2/4/2018 9:28 PM, Bjørn Mork wrote:
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote:
It's 662591461c4b9a1e3b9b159dbf37648a585ebaae. To my eyes, it even
looks plausible that it's causing the problematic behaviour, but
since I can't say I understand what I'd be doing if I dabbled with
the change, I've refrained from guessing how to fix it.
I'm happy to try patches, though.
Ok, thanks. I've added the authors of this patch to the email here,
perhaps they have an idea of what is going on?
This thing made me curious enough to dive into code I don't understand,
as I have experienced the annoying crazy fan behaviour in resume a few
times on my X1 Carbon 4th gen.
Maybe I missed something, but it looks like commit
c3a696b6e8f8 ("ACPI / EC: Use busy polling mode when GPE is not enabled")
introduced suspend/resume busy polling for the "boot EC" unintentionally?
The patch moved acpi_ec_leave_noirq() and acpi_ec_leave_noirq()
functions outside the #ifdef CONFIG_PM_SLEEP, so they could be reused
while installing handlers. But when doing that the
if (ec == first_ec)
conditions on suspend/resume were silently dropped. I assume the
intention might have been to move those intto acpi_ec_suspend_noirq()
and acpi_ec_resume_noirq() instead? But that didn't happen AFAICS.
Or did I misunderstand this completely? Not unlikely given that I have
zero clue about what this code is doing...
But I do wonder if the attached (completely untested!!) patch makes
things any better?
I don't think so, the macro is needed too.
I'll queue up a full revert of 662591461c4b9a1e3b.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
