* [PATCH v2] pinctrl: amd: Clear S4 wake bits when firmware has _AEI
@ 2026-10-05 18:01 Mario Limonciello
2026-10-07 11:27 ` Linus Walleij
0 siblings, 1 reply; 3+ messages in thread
From: Mario Limonciello @ 2026-10-05 18:01 UTC (permalink / raw)
To: Basavaraj.Natikar, Shyam-sundar.S-k, linusw, mario.limonciello
Cc: Olzhas Marat, stable, linux-gpio
Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
preserves firmware-programmed S4 wake sources because some PCIe devices
rely on them for Wake-on-LAN. The system that motivated that change does
not expose ACPI GPIO events through _AEI.
On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5
wake bit set for GPIO 24. This causes the machine to power back on
immediately after shutdown even though Wake-on-LAN is not enabled.
GPIO register dumps show that the only relevant difference is bit 15 on
GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not
itself listed in _AEI, so _AEI is not a per-pin indication of which pins
the OS manages; it is a platform level signal of which wake model the
firmware follows.
Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on
every system. Clear S4 bits when firmware exposes _AEI, indicating that the
platform hands GPIO events to the OS, but preserve S4 bits when _AEI is
absent so that firmware-programmed sources such as PCIe PME that bypass the
GPIO IRQ wake API keep working.
A platform that exposes _AEI for some pins while routing a wake capable
device through a raw GPIO not listed in _AEI would lose that wake source
unless firmware re-arms it during the sleep transition. No such system has
been reported.
Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
Reported-by: Olzhas Marat <marat.olzhas@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041
Cc: stable@vger.kernel.org
Tested-by: Olzhas Marat <marat.olzhas@gmail.com>
Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2:
* Add tag
* Drop handle declaration
---
drivers/pinctrl/pinctrl-amd.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 15a398bb3be23..6835e943909ca 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -886,6 +886,15 @@ static void amd_gpio_irq_init(struct amd_gpio *gpio_dev)
mask = BIT(WAKE_CNTRL_OFF_S0I3) | BIT(WAKE_CNTRL_OFF_S3);
+#ifdef CONFIG_ACPI
+ /*
+ * Platforms without _AEI leave GPIO wake sources to firmware, so
+ * preserve their S4 wake bits.
+ */
+ if (acpi_has_method(ACPI_HANDLE(&gpio_dev->pdev->dev), "_AEI"))
+ mask |= BIT(WAKE_CNTRL_OFF_S4);
+#endif
+
for (i = 0; i < desc->npins; i++) {
int pin = desc->pins[i].number;
const struct pin_desc *pd = pin_desc_get(gpio_dev->pctrl, pin);
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v2] pinctrl: amd: Clear S4 wake bits when firmware has _AEI
2026-10-05 18:01 [PATCH v2] pinctrl: amd: Clear S4 wake bits when firmware has _AEI Mario Limonciello
@ 2026-10-07 11:27 ` Linus Walleij
2026-10-07 19:24 ` Mario Limonciello
0 siblings, 1 reply; 3+ messages in thread
From: Linus Walleij @ 2026-10-07 11:27 UTC (permalink / raw)
To: Mario Limonciello
Cc: Basavaraj.Natikar, Shyam-sundar.S-k, Olzhas Marat, stable,
linux-gpio
On Mon, Oct 5, 2026 at 8:02 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
> Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
> preserves firmware-programmed S4 wake sources because some PCIe devices
> rely on them for Wake-on-LAN. The system that motivated that change does
> not expose ACPI GPIO events through _AEI.
>
> On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5
> wake bit set for GPIO 24. This causes the machine to power back on
> immediately after shutdown even though Wake-on-LAN is not enabled.
>
> GPIO register dumps show that the only relevant difference is bit 15 on
> GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not
> itself listed in _AEI, so _AEI is not a per-pin indication of which pins
> the OS manages; it is a platform level signal of which wake model the
> firmware follows.
>
> Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on
> every system. Clear S4 bits when firmware exposes _AEI, indicating that the
> platform hands GPIO events to the OS, but preserve S4 bits when _AEI is
> absent so that firmware-programmed sources such as PCIe PME that bypass the
> GPIO IRQ wake API keep working.
>
> A platform that exposes _AEI for some pins while routing a wake capable
> device through a raw GPIO not listed in _AEI would lose that wake source
> unless firmware re-arms it during the sleep transition. No such system has
> been reported.
>
> Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
> Reported-by: Olzhas Marat <marat.olzhas@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041
> Cc: stable@vger.kernel.org
> Tested-by: Olzhas Marat <marat.olzhas@gmail.com>
> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] pinctrl: amd: Clear S4 wake bits when firmware has _AEI
2026-10-07 11:27 ` Linus Walleij
@ 2026-10-07 19:24 ` Mario Limonciello
0 siblings, 0 replies; 3+ messages in thread
From: Mario Limonciello @ 2026-10-07 19:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Basavaraj.Natikar, Shyam-sundar.S-k, Olzhas Marat, stable,
linux-gpio
On 10/7/26 06:27, Linus Walleij wrote:
> On Mon, Oct 5, 2026 at 8:02 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>
>> Commit ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
>> preserves firmware-programmed S4 wake sources because some PCIe devices
>> rely on them for Wake-on-LAN. The system that motivated that change does
>> not expose ACPI GPIO events through _AEI.
>>
>> On a Chuwi CoreBook Plus, firmware exposes _AEI but also leaves the S4/S5
>> wake bit set for GPIO 24. This causes the machine to power back on
>> immediately after shutdown even though Wake-on-LAN is not enabled.
>>
>> GPIO register dumps show that the only relevant difference is bit 15 on
>> GPIO 24. Clearing that bit makes the machine remain off. GPIO 24 is not
>> itself listed in _AEI, so _AEI is not a per-pin indication of which pins
>> the OS manages; it is a platform level signal of which wake model the
>> firmware follows.
>>
>> Use that signal to decide what to clear. Continue clearing S0i3/S3 bits on
>> every system. Clear S4 bits when firmware exposes _AEI, indicating that the
>> platform hands GPIO events to the OS, but preserve S4 bits when _AEI is
>> absent so that firmware-programmed sources such as PCIe PME that bypass the
>> GPIO IRQ wake API keep working.
>>
>> A platform that exposes _AEI for some pins while routing a wake capable
>> device through a raw GPIO not listed in _AEI would lose that wake source
>> unless firmware re-arms it during the sleep transition. No such system has
>> been reported.
>>
>> Fixes: ffe8a0c6b552 ("pinctrl-amd: Don't clear S4 wake bits at probe")
>> Reported-by: Olzhas Marat <marat.olzhas@gmail.com>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222041
>> Cc: stable@vger.kernel.org
>> Tested-by: Olzhas Marat <marat.olzhas@gmail.com>
>> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>
> Patch applied for fixes.
>
> Yours,
> Linus Walleij
Thanks!
Next cycle I'll send out a change to drop the #ifdef CONFIG_ACPI (there
is a change in linux-next that adds a stub).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-07 19:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-05 18:01 [PATCH v2] pinctrl: amd: Clear S4 wake bits when firmware has _AEI Mario Limonciello
2026-10-07 11:27 ` Linus Walleij
2026-10-07 19:24 ` Mario Limonciello
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox