drivers/gpio/gpiolib-acpi-quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
The ASUS TX Air FA401GM experiences immediate wakeups from s2idle
(Modern Standby) when suspended with an external HDMI display connected.
This issue is caused by spurious ACPI event signaling routed through
GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a
system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep.
Add an ignore_wake quirk for GPIO 24 on this machine to prevent these
unwanted wakeups. This has been runtime-tested and verified using the
`gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter.
Signed-off-by: Yao Qi <xnorigc@gmail.com>
---
drivers/gpio/gpiolib-acpi-quirks.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004..8d7d18b62 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,6 +392,19 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
.ignore_wake = "VEN_0488:00@355",
},
},
+ {
+ /*
+ * Spurious wakeups from s2idle when suspended with an
+ * external HDMI display connected.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TX Air FA401GM"),
+ },
+ .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+ .ignore_wake = "AMDI0030:00@24",
+ },
+ },
{} /* Terminating entry */
};
--
2.55.0On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > (Modern Standby) when suspended with an external HDMI display connected. > > This issue is caused by spurious ACPI event signaling routed through > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > unwanted wakeups. This has been runtime-tested and verified using the > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. Mario, can you ack this one? -- With Best Regards, Andy Shevchenko
On 8/23/26 03:25, Andy Shevchenko wrote: > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: >> The ASUS TX Air FA401GM experiences immediate wakeups from s2idle >> (Modern Standby) when suspended with an external HDMI display connected. >> >> This issue is caused by spurious ACPI event signaling routed through >> GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a >> system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. >> >> Add an ignore_wake quirk for GPIO 24 on this machine to prevent these >> unwanted wakeups. This has been runtime-tested and verified using the >> `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. > > Mario, can you ack this one? > It's likely very similar to https://lore.kernel.org/linux-gpio/20260821070651.39763-1-vaknins33@gmail.com/ As you can see that's also GPIO pin 24. Can we please see an acpidump to confirm though?
On Mon, Aug 24, 2026 at 10:12:18AM -0500, Mario Limonciello wrote: > On 8/23/26 03:25, Andy Shevchenko wrote: > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > > > (Modern Standby) when suspended with an external HDMI display connected. > > > > > > This issue is caused by spurious ACPI event signaling routed through > > > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > > > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > > > > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > > > unwanted wakeups. This has been runtime-tested and verified using the > > > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. > > > > Mario, can you ack this one? > > It's likely very similar to > > https://lore.kernel.org/linux-gpio/20260821070651.39763-1-vaknins33@gmail.com/ > > As you can see that's also GPIO pin 24. Right, but this will need still its own DMI entry, will it? > Can we please see an acpidump to confirm though? -- With Best Regards, Andy Shevchenko
On 9/3/26 06:55, Andy Shevchenko wrote: > On Mon, Aug 24, 2026 at 10:12:18AM -0500, Mario Limonciello wrote: >> On 8/23/26 03:25, Andy Shevchenko wrote: >>> On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: >>>> The ASUS TX Air FA401GM experiences immediate wakeups from s2idle >>>> (Modern Standby) when suspended with an external HDMI display connected. >>>> >>>> This issue is caused by spurious ACPI event signaling routed through >>>> GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a >>>> system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. >>>> >>>> Add an ignore_wake quirk for GPIO 24 on this machine to prevent these >>>> unwanted wakeups. This has been runtime-tested and verified using the >>>> `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. >>> >>> Mario, can you ack this one? >> >> It's likely very similar to >> >> https://lore.kernel.org/linux-gpio/20260821070651.39763-1-vaknins33@gmail.com/ >> >> As you can see that's also GPIO pin 24. > > Right, but this will need still its own DMI entry, will it? > Right. We just need to look through the acpidump to confirm this. >> Can we please see an acpidump to confirm though? >
On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > (Modern Standby) when suspended with an external HDMI display connected. > > This issue is caused by spurious ACPI event signaling routed through > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > unwanted wakeups. This has been runtime-tested and verified using the > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. If AMD people will be quick enough to tag this, I will include in my PR to Linus W. on next week. -- With Best Regards, Andy Shevchenko
On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > > (Modern Standby) when suspended with an external HDMI display connected. > > > > This issue is caused by spurious ACPI event signaling routed through > > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > > unwanted wakeups. This has been runtime-tested and verified using the > > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. > > If AMD people will be quick enough to tag this, I will include in my PR to > Linus W. on next week. To Bartosz? It's gpiolib... Yours, Linus Walleij
On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > > > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > > > (Modern Standby) when suspended with an external HDMI display connected. > > > > > > This issue is caused by spurious ACPI event signaling routed through > > > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > > > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > > > > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > > > unwanted wakeups. This has been runtime-tested and verified using the > > > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. > > > > If AMD people will be quick enough to tag this, I will include in my PR to > > Linus W. on next week. > > To Bartosz? > It's gpiolib... Oh, true, I have also pin control stuff to send! -- With Best Regards, Andy Shevchenko
On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: > On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: > > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > > > > > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle > > > > (Modern Standby) when suspended with an external HDMI display connected. > > > > > > > > This issue is caused by spurious ACPI event signaling routed through > > > > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a > > > > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. > > > > > > > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these > > > > unwanted wakeups. This has been runtime-tested and verified using the > > > > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. > > > > > > If AMD people will be quick enough to tag this, I will include in my PR to > > > Linus W. on next week. > > > > To Bartosz? > > It's gpiolib... > > Oh, true, I have also pin control stuff to send! Okay, I have checked if I have anything to Bart and it seems I mixed that with pin control stuff. So, Bart, if you feel confident about this patch, you can take it directly. Here is my formal tag for that Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> -- With Best Regards, Andy Shevchenko
On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko <andriy.shevchenko@linux.intel.com> said: > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko >> > <andriy.shevchenko@linux.intel.com> wrote: >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: >> > >> > > > The ASUS TX Air FA401GM experiences immediate wakeups from s2idle >> > > > (Modern Standby) when suspended with an external HDMI display connected. >> > > > >> > > > This issue is caused by spurious ACPI event signaling routed through >> > > > GPIO 24 on the AMD GPIO controller (AMDI0030:00), which triggers a >> > > > system-wide IRQ 7 (pinctrl_amd) wake-up interrupt during sleep. >> > > > >> > > > Add an ignore_wake quirk for GPIO 24 on this machine to prevent these >> > > > unwanted wakeups. This has been runtime-tested and verified using the >> > > > `gpiolib_acpi.ignore_wake=AMDI0030:00@24` kernel parameter. >> > > >> > > If AMD people will be quick enough to tag this, I will include in my PR to >> > > Linus W. on next week. >> > >> > To Bartosz? >> > It's gpiolib... >> >> Oh, true, I have also pin control stuff to send! > > Okay, I have checked if I have anything to Bart and it seems I mixed that with > pin control stuff. So, Bart, if you feel confident about this patch, you can > take it directly. Here is my formal tag for that > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Is this a bugfix? I'll be OoO until the end of August starting on Friday with the exception of a single day to catch up on email. I'll be sending my PRs for v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? Bart
On Wed, Aug 12, 2026 at 01:23:53AM -0700, Bartosz Golaszewski wrote: > On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> said: > > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: > >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: > >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko > >> > <andriy.shevchenko@linux.intel.com> wrote: > >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: ... > >> > > If AMD people will be quick enough to tag this, I will include in my PR to > >> > > Linus W. on next week. > >> > > >> > To Bartosz? > >> > It's gpiolib... > >> > >> Oh, true, I have also pin control stuff to send! > > > > Okay, I have checked if I have anything to Bart and it seems I mixed that with > > pin control stuff. So, Bart, if you feel confident about this patch, you can > > take it directly. Here is my formal tag for that > > > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Is this a bugfix? I'll be OoO until the end of August starting on Friday with > the exception of a single day to catch up on email. I'll be sending my PRs for > v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? On one hand there is no rocket science behind this patch (that's why I gave my tag), but if you strictly want AMD to confirm, then postpone, so it's up to you to decide. -- With Best Regards, Andy Shevchenko
On Wed, 12 Aug 2026 10:39:53 +0200, Andy Shevchenko <andriy.shevchenko@linux.intel.com> said: > On Wed, Aug 12, 2026 at 01:23:53AM -0700, Bartosz Golaszewski wrote: >> On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko >> <andriy.shevchenko@linux.intel.com> said: >> > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: >> >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: >> >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko >> >> > <andriy.shevchenko@linux.intel.com> wrote: >> >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > ... > >> >> > > If AMD people will be quick enough to tag this, I will include in my PR to >> >> > > Linus W. on next week. >> >> > >> >> > To Bartosz? >> >> > It's gpiolib... >> >> >> >> Oh, true, I have also pin control stuff to send! >> > >> > Okay, I have checked if I have anything to Bart and it seems I mixed that with >> > pin control stuff. So, Bart, if you feel confident about this patch, you can >> > take it directly. Here is my formal tag for that >> > >> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> >> >> Is this a bugfix? I'll be OoO until the end of August starting on Friday with >> the exception of a single day to catch up on email. I'll be sending my PRs for >> v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? > > On one hand there is no rocket science behind this patch (that's why I gave my tag), > but if you strictly want AMD to confirm, then postpone, so it's up to you to decide. > If this is not an important bugfix, then let me postpone it until next cycle. Bart
On Wed, Aug 12, 2026 at 06:54:30AM -0500, Bartosz Golaszewski wrote: > On Wed, 12 Aug 2026 10:39:53 +0200, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> said: > > On Wed, Aug 12, 2026 at 01:23:53AM -0700, Bartosz Golaszewski wrote: > >> On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko > >> <andriy.shevchenko@linux.intel.com> said: > >> > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: > >> >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: > >> >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko > >> >> > <andriy.shevchenko@linux.intel.com> wrote: > >> >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: ... > >> >> > > If AMD people will be quick enough to tag this, I will include in my PR to > >> >> > > Linus W. on next week. > >> >> > > >> >> > To Bartosz? > >> >> > It's gpiolib... > >> >> > >> >> Oh, true, I have also pin control stuff to send! > >> > > >> > Okay, I have checked if I have anything to Bart and it seems I mixed that with > >> > pin control stuff. So, Bart, if you feel confident about this patch, you can > >> > take it directly. Here is my formal tag for that > >> > > >> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > >> > >> Is this a bugfix? I'll be OoO until the end of August starting on Friday with > >> the exception of a single day to catch up on email. I'll be sending my PRs for > >> v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? > > > > On one hand there is no rocket science behind this patch (that's why I gave my tag), > > but if you strictly want AMD to confirm, then postpone, so it's up to you to decide. > > If this is not an important bugfix, then let me postpone it until next cycle. I believe a user may survive with this bug to be present for a bit longer. But not my call, at Intel I have no such hardware :-) -- With Best Regards, Andy Shevchenko
On Wed, 12 Aug 2026 15:16:36 +0200, Andy Shevchenko <andriy.shevchenko@linux.intel.com> said: > On Wed, Aug 12, 2026 at 06:54:30AM -0500, Bartosz Golaszewski wrote: >> On Wed, 12 Aug 2026 10:39:53 +0200, Andy Shevchenko >> <andriy.shevchenko@linux.intel.com> said: >> > On Wed, Aug 12, 2026 at 01:23:53AM -0700, Bartosz Golaszewski wrote: >> >> On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko >> >> <andriy.shevchenko@linux.intel.com> said: >> >> > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: >> >> >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: >> >> >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko >> >> >> > <andriy.shevchenko@linux.intel.com> wrote: >> >> >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: > > ... > >> >> >> > > If AMD people will be quick enough to tag this, I will include in my PR to >> >> >> > > Linus W. on next week. >> >> >> > >> >> >> > To Bartosz? >> >> >> > It's gpiolib... >> >> >> >> >> >> Oh, true, I have also pin control stuff to send! >> >> > >> >> > Okay, I have checked if I have anything to Bart and it seems I mixed that with >> >> > pin control stuff. So, Bart, if you feel confident about this patch, you can >> >> > take it directly. Here is my formal tag for that >> >> > >> >> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> >> >> >> >> Is this a bugfix? I'll be OoO until the end of August starting on Friday with >> >> the exception of a single day to catch up on email. I'll be sending my PRs for >> >> v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? >> > >> > On one hand there is no rocket science behind this patch (that's why I gave my tag), >> > but if you strictly want AMD to confirm, then postpone, so it's up to you to decide. >> >> If this is not an important bugfix, then let me postpone it until next cycle. > > I believe a user may survive with this bug to be present for a bit longer. > But not my call, at Intel I have no such hardware :-) > No worries, it can go upstream right after I'm back from vacations. Bart
On Wed, Aug 12, 2026 at 06:39:20AM -0700, Bartosz Golaszewski wrote: > On Wed, 12 Aug 2026 15:16:36 +0200, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> said: > > On Wed, Aug 12, 2026 at 06:54:30AM -0500, Bartosz Golaszewski wrote: > >> On Wed, 12 Aug 2026 10:39:53 +0200, Andy Shevchenko > >> <andriy.shevchenko@linux.intel.com> said: > >> > On Wed, Aug 12, 2026 at 01:23:53AM -0700, Bartosz Golaszewski wrote: > >> >> On Tue, 11 Aug 2026 16:54:29 +0200, Andy Shevchenko > >> >> <andriy.shevchenko@linux.intel.com> said: > >> >> > On Mon, Aug 10, 2026 at 11:36:19AM +0300, Andy Shevchenko wrote: > >> >> >> On Mon, Aug 10, 2026 at 12:17:06AM +0200, Linus Walleij wrote: > >> >> >> > On Sat, Aug 8, 2026 at 9:42 PM Andy Shevchenko > >> >> >> > <andriy.shevchenko@linux.intel.com> wrote: > >> >> >> > > On Sat, Aug 08, 2026 at 03:55:13PM +0000, Yao Qi wrote: ... > >> >> >> > > If AMD people will be quick enough to tag this, I will include in my PR to > >> >> >> > > Linus W. on next week. > >> >> >> > > >> >> >> > To Bartosz? > >> >> >> > It's gpiolib... > >> >> >> > >> >> >> Oh, true, I have also pin control stuff to send! > >> >> > > >> >> > Okay, I have checked if I have anything to Bart and it seems I mixed that with > >> >> > pin control stuff. So, Bart, if you feel confident about this patch, you can > >> >> > take it directly. Here is my formal tag for that > >> >> > > >> >> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > >> >> > >> >> Is this a bugfix? I'll be OoO until the end of August starting on Friday with > >> >> the exception of a single day to catch up on email. I'll be sending my PRs for > >> >> v7.3 tomorrow. Not sure if I should take it for v7.3 or v7.2? > >> > > >> > On one hand there is no rocket science behind this patch (that's why I gave my tag), > >> > but if you strictly want AMD to confirm, then postpone, so it's up to you to decide. > >> > >> If this is not an important bugfix, then let me postpone it until next cycle. > > > > I believe a user may survive with this bug to be present for a bit longer. > > But not my call, at Intel I have no such hardware :-) > > > > No worries, it can go upstream right after I'm back from vacations. Since there is another similar patch pending, I will take them all into my branch and issue a fix PR after -rc1. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.