Re: [PATCH v2 2/3] ACPI: button: Enable wakeup GPEs for ACPI buttons at probe time

[Rafael J. Wysocki]

On Sat, May 23, 2026 at 4:15 AM Nick <nick@xxxxxxxx> wrote:
>
>
>
> On May 22, 2026 2:52:10 p.m. UTC, "Rafael J. Wysocki" <rafael@xxxxxxxxxx> wrote:
> >From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >
> >Prior to commit 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake()
> >for buttons"), ACPI button wakeup GPEs having handler methods remained
> >enabled after acpi_wakeup_gpe_init(), but currently they are not enabled
> >because acpi_setup_gpe_for_wake() disables them.
> >
> >That causes function keys to stop working on some systems [1] and there
> >may be other related issues elsewhere.
> >
> >To address that, make the ACPI button driver enable wakeup GPEs for ACPI
> >buttons so long as they have handler methods.  While this does not
> >restore the old behavior exactly (the ACPI button driver needs to be
> >bound to the button devices for the GPEs to be enabled), it should be
> >sufficient to restore the missing functionality.
> >
> >For this purpose, introduce acpi_enable_gpe_cond() that enables
> >a GPE if its dispatch type matches the supplied one and modify
> >acpi_button_probe() to use that function for enabling the GPEs in
> >question.
> >
> >Fixes: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons")
> >Reported-by: Nick <nick@xxxxxxxx>
> >Closes: https://lore.kernel.org/linux-acpi/E2OXET.4X5GTP37VTNC3@xxxxxxxx/ [1]
> >Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >Cc: 7.0+ <stable@xxxxxxxxxxxxxxx> # 7.0+
> >---
> >
> >v1 -> v2:
> >   * Change the acpi_enable_gpe_cond() third parameter to a dispatch type (or
> >     "any type" value) and modify checks in it accordingly to address a
> >     problem pointed out by sashiko.dev
> >   * Adjust comments in acpi_enable_gpe_cond() and acpi_enable_gpe()
> >   * Update the changelog
> >
> >@Nick, It would be good to test this version of the patch on your system
> >because it is a bit different from the previous one (which was not entirely
> >correct).  I'm not expecting it to behave differently, but additional
> >testing would be welcome.
> >
>
>
> I tested this on top of 45255ea1ca096. The keys are still working as expected! I compared it against 6.19.14 too and all the keys seem to behave as before.

Thanks for the confirmation!

I'll add a Tested-by tag for you to the patch when applying it unless
you don't want me to do that.

> I noticed one difference, but it might not be directly related: KEY_SLEEP takes significantly longer
> to trigger suspend on 7.1-rc4 than on 6.19.14. On the older version it suspends in about a second;
> on 7.1-rc4 it takes about a minute before it fully suspends. The lid switch on the other hand suspends
> in about a second, and so does the suspend button in my DE, on both versions.

This is unlikely to be related to the issue addressed by the $subject patch.

> I guess they're doing different kinds of suspend. That's probably related to the other ACPI changes
> that landed in 7.0.

One thing to take into consideration here is that the kernel doesn't
trigger suspend by itself.  The
key press event first goes to user space which then decides what to do
with it and may (or may
not) trigger a system suspend in response.  It may be doing different
things for KEY_SLEEP and
the lid switch.