Re: [PATCH v5 2/4] platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops

[Daniel Gibson]

On 09.06.26 16:40, Mario Limonciello wrote:
> On 6/9/26 07:07, Daniel Gibson wrote:
>> On 09.06.26 13:46, Ilpo Järvinen wrote:
>>> On Tue, 9 Jun 2026, Daniel Gibson wrote:
>>>
>>>> Some IdeaPad Slim 3 devices and similar with AMD CPUs have a
>>>> nonfunctional keyboard and lid switch after s2idle.
>>>>
>>>> It helps to delay suspend by 2.5 seconds so the EC has some time
>>>> to do whatever it needs to get done before suspend - unfortunately
>>>> at least on my 16ABR8 waking it with a timer (wakealarm) still
>>>> triggers the issue, but at least normal resume via keypress or
>>>> lid works fine. On the 14ARP10 wakealarm has been reported to also
>>>> work fine with this patch.
>>>>
>>>> This issue has been reported for many different devices, this patch
>>>> has been tested with the Zen3-based IdeaPad Slim 3 16ABR8 (82XR)
>>>> and the Zen3+-based IdeaPad Slim 3 14ARP10 (83K6) and IdeaPad Slim 3
>>>> 15ARP10 (83MM).
>>>>
>>>> Reported-by: Sindre Henriksen <sindrehenriksen93@xxxxxxxxx>
>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221383
>>>> Tested-by: Sindre Henriksen <sindrehenriksen93@xxxxxxxxx>
>>>> Suggested-by: Mario Limonciello (AMD) <superm1@xxxxxxxxxx>
>>>> Reviewed-by: Mario Limonciello (AMD) <superm1@xxxxxxxxxx>
>>>> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
>>>> Reviewed-by: Hans de Goede <johannes.goede@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Daniel Gibson <daniel@xxxxxxxxx>
>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>> ---
>>>>   drivers/platform/x86/amd/pmc/pmc-quirks.c | 39 +++++++++++++++++++
>>>> ++++
>>>>   drivers/platform/x86/amd/pmc/pmc.c        | 24 +++++++++++++-
>>>>   drivers/platform/x86/amd/pmc/pmc.h        |  1 +
>>>>   3 files changed, 63 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/
>>>> platform/x86/amd/pmc/pmc-quirks.c
>>>> index 24506e342943..74ddf1d8289a 100644
>>>> --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>>> +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
>>>> @@ -18,6 +18,7 @@
>>>>   struct quirk_entry {
>>>>       u32 s2idle_bug_mmio;
>>>>       bool spurious_8042;
>>>> +    bool need_suspend_delay;
>>>>   };
>>>>     static struct quirk_entry quirk_s2idle_bug = {
>>>> @@ -33,6 +34,10 @@ static struct quirk_entry
>>>> quirk_s2idle_spurious_8042 = {
>>>>       .spurious_8042 = true,
>>>>   };
>>>>   +static struct quirk_entry quirk_s2idle_need_suspend_delay = {
>>>> +    .need_suspend_delay = true,
>>>> +};
>>>> +
>>>>   static const struct dmi_system_id fwbug_list[] = {
>>>>       {
>>>>           .ident = "L14 Gen2 AMD",
>>>> @@ -203,6 +208,35 @@ static const struct dmi_system_id fwbug_list[] = {
>>>>               DMI_MATCH(DMI_PRODUCT_NAME, "82XQ"),
>>>>           }
>>>>       },
>>>> +    /* https://bugzilla.kernel.org/show_bug.cgi?id=221383 */
>>>> +    {
>>>> +        .ident = "Zen3-based IdeaPad Slim and similar",
>>>> +        .driver_data = &quirk_s2idle_need_suspend_delay,
>>>
>>> Hi,
>>>
>>> One more question.
>>>
>>> Sashiko noted, that amd_pmc_quirks_init() can overwrite
>>> disable_8042_wakeup from the AMD_CPU_ID_CZN check when .driver_data
>>> provides quirks. Is it okay in this case to not have .spurious_8042?
>>>
>>
>> Good question.
>> So far I haven't had complaints that sounded like they'd be related to
>> this quirk not being active.
>>
>> (The only report about things not working as expected on detected
>> devices was something about "ACPI event storms" after resume:
>> https://github.com/DanielGibson/amd_pmc-ideapad/issues/3 - but no one
>> else with similar devices could reproduce that, so no idea what's going
>> on there, and it doesn't sound like that IRQ1 issue)
>>
>> I can test if explicitly enabling .spurious_8042 in
>> quirk_s2idle_need_suspend_delay breaks anything on my device, if you
>> think that enabling it by default makes more sense?
> 
> Famous last words - but we haven't had a need for spurious 8042 on
> recent hardware so I think this is unlikely to be a big problem.

FWIW enabling .spurious_8042 didn't break anything on my machine, but
didn't improve anything either - only visible difference is that when
resuming by pressing a key without that quirk both IRQ1 and IRQ7 are
reported as having triggered the resume, and with the quirk only IRQ7 is
reported. But it didn't seem like IRQ1 triggers a resume when it shouldn't.

OTOH I have a the latest BIOS (from this year), so it's likely fixed
there - maybe people with older BIOS versions still need the
.spurious_8042 quirk?

As these devices are relatively recent and still sold I hope that
everyone affected can get a new BIOS (which they should do either way).