Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

["Rafael J. Wysocki" <rafael.j.wysocki@intel.com>]

On 2/4/2018 9:28 PM, Bjørn Mork wrote:
> Greg KH <gregkh@linuxfoundation.org> 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