[PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Marco Scardovi]

The ASUS ROG Strix G16 G614 series laptops experience a long boot delay of
approximately 36 seconds. This happens because the system firmware triggers
a slow/hanging ActiveBoth GPIO interrupt handler at boot time.

Even though commit 3bb62e3f99a5 ("gpiolib: acpi: Only trigger ActiveBoth
interrupts on boot") restricted boot-time execution to ActiveBoth edge
events, the problematic interrupt on these laptops is configured as
ActiveBoth. Consequently, the handler is still executed at boot and
the boot process stalls.

Fix the delay by adding a DMI quirk to disable edge event execution at
boot for the ASUS ROG Strix G16 G614 family.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 drivers/gpio/gpiolib-acpi-quirks.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004975..fa0f03bd51af 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,6 +392,20 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
 			.ignore_wake = "VEN_0488:00@355",
 		},
 	},
+	{
+		/*
+		 * ASUS ROG Strix G614 series laptops experience a long boot
+		 * delay (approx. 36 seconds) due to a slow/hanging ActiveBoth
+		 * GPIO interrupt handler executing at boot.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.no_edge_events_on_boot = true,
+		},
+	},
 	{} /* Terminating entry */
 };
 
-- 
2.54.0

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 11:08:24AM +0200, Marco Scardovi wrote:
> The ASUS ROG Strix G16 G614 series laptops experience a long boot delay of
> approximately 36 seconds. This happens because the system firmware triggers
> a slow/hanging ActiveBoth GPIO interrupt handler at boot time.

'slow'? Did you mean 'low'?

> Even though commit 3bb62e3f99a5 ("gpiolib: acpi: Only trigger ActiveBoth
> interrupts on boot") restricted boot-time execution to ActiveBoth edge
> events, the problematic interrupt on these laptops is configured as
> ActiveBoth. Consequently, the handler is still executed at boot and
> the boot process stalls.
> 
> Fix the delay by adding a DMI quirk to disable edge event execution at
> boot for the ASUS ROG Strix G16 G614 family.

What is this interrupt for? Touchpad?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Marco Scardovi]

Hi Andy,

> 'slow'? Did you mean 'low'?

Yes, sorry, that was a typo. I meant 'low'.

> What is this interrupt for? Touchpad?

It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
Specifically, it triggers on pin 21, appearing in /proc/interrupts as
"amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.

Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
"gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
bypassed the 36-second delay, which confirms this specific pin/handler is the
culprit stalling the boot process.

Thanks for the review!

Marco

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 11:43:56AM +0200, Marco Scardovi wrote:

...

> > What is this interrupt for? Touchpad?
> 
> It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
> Specifically, it triggers on pin 21, appearing in /proc/interrupts as
> "amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.
> 
> Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
> "gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
> bypassed the 36-second delay, which confirms this specific pin/handler is the
> culprit stalling the boot process.

Mika, do you see any problems with disabled (deferred?) interrupt for this type
of event? I think it might break the suspend-resume (on touchpad event). Also
do you remember if we ever had touchpad event to be ActiveBoth?

What I'm trying to understand if this is pure BIOS issue (typo) or HW really
wants to
- be able to generate events to the OS (at boot time?)
- have the reaction on any edge

Mario, do you know anything more? It's AMD platform at the end, what the TP
model and if it requires both edges...

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Mika Westerberg]

On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 11:43:56AM +0200, Marco Scardovi wrote:
> 
> ...
> 
> > > What is this interrupt for? Touchpad?
> > 
> > It is an ACPI event interrupt on the AMD GPIO controller (AMDI0030).
> > Specifically, it triggers on pin 21, appearing in /proc/interrupts as
> > "amd_gpio 21 ACPI:Event" and as you guessed it is the touchpad.
> > 
> > Previously, using "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" or
> > "gpiolib_acpi.run_edge_events_on_boot=0" as a boot parameter successfully
> > bypassed the 36-second delay, which confirms this specific pin/handler is the
> > culprit stalling the boot process.
> 
> Mika, do you see any problems with disabled (deferred?) interrupt for this type
> of event? I think it might break the suspend-resume (on touchpad event). Also
> do you remember if we ever had touchpad event to be ActiveBoth?

For starters, why this is ACPI event in the first place? The AML is not
supposed to use the touchpad.

Touchpad should be using just regular GpioInt(). Does it still work after
this patch? If yes then I think this is definitely okay.

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Marco Scardovi]

On Tue, Jun 16, 2026 at 12:24:51 +0200, Mika Westerberg wrote:
> On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> > Mika, do you see any problems with disabled (deferred?) interrupt for this 
type
> > of event? I think it might break the suspend-resume (on touchpad event). 
Also
> > do you remember if we ever had touchpad event to be ActiveBoth?
> 
> For starters, why this is ACPI event in the first place? The AML is not
> supposed to use the touchpad.
> 
> Touchpad should be using just regular GpioInt(). Does it still work after
> this patch? If yes then I think this is definitely okay.

Hi Mika, Andy,

Yes, the touchpad continues to work perfectly after this patch (even the
suspend/resume you asked about).

The touchpad itself is initialized and driven by the i2c-hid driver using a 
standard GpioInt() resource defined in the touchpad device's _CRS method. 
The ACPI event handler (pin 21) registered under the GPIO controller's _AEI 
is distinct from this.

The DMI quirk (.no_edge_events_on_boot = true) only prevents the initial 
boot-time trigger of this ACPI event handler when the line is asserted low 
during initialization. It does not prevent the touchpad driver from 
requesting and receiving its interrupts.

Furthermore, unlike using the "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" 
workaround (which would completely disable the ACPI handler), this patch still 
keeps the ACPI event handler registered. If any edge events occur on this pin 
post-boot (for example, if the BIOS needs to toggle touchpad states or track 
device status), the handler will still run normally, avoiding any potential 
breakage of runtime ACPI functionality.

Sidenote
Personally I'd wait for Mario for further info: after all it's him the
maintainer for AMD side and surely knows more than me.

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 12:58:31PM +0200, Marco Scardovi wrote:
> On Tue, Jun 16, 2026 at 12:24:51 +0200, Mika Westerberg wrote:
> > On Tue, Jun 16, 2026 at 12:58:04PM +0300, Andy Shevchenko wrote:
> > > Mika, do you see any problems with disabled (deferred?) interrupt for
> > > this type of event? I think it might break the suspend-resume (on
> > > touchpad event). Also do you remember if we ever had touchpad event to
> > > be ActiveBoth?
> > 
> > For starters, why this is ACPI event in the first place? The AML is not
> > supposed to use the touchpad.
> > 
> > Touchpad should be using just regular GpioInt(). Does it still work after
> > this patch? If yes then I think this is definitely okay.
> 
> Yes, the touchpad continues to work perfectly after this patch (even the
> suspend/resume you asked about).
> 
> The touchpad itself is initialized and driven by the i2c-hid driver using a 
> standard GpioInt() resource defined in the touchpad device's _CRS method. 
> The ACPI event handler (pin 21) registered under the GPIO controller's _AEI 
> is distinct from this.
> 
> The DMI quirk (.no_edge_events_on_boot = true) only prevents the initial 
> boot-time trigger of this ACPI event handler when the line is asserted low 
> during initialization. It does not prevent the touchpad driver from 
> requesting and receiving its interrupts.
> 
> Furthermore, unlike using the "gpiolib_acpi.ignore_interrupt=AMDI0030:00@21" 
> workaround (which would completely disable the ACPI handler), this patch still 
> keeps the ACPI event handler registered. If any edge events occur on this pin 
> post-boot (for example, if the BIOS needs to toggle touchpad states or track 
> device status), the handler will still run normally, avoiding any potential 
> breakage of runtime ACPI functionality.

Okay, perhaps this all needs to be elaborated and summarized in the commit message.

> Sidenote
> Personally I'd wait for Mario for further info: after all it's him the
> maintainer for AMD side and surely knows more than me.

Sure, I am with you on this.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Marco Scardovi]

> 
> Okay, perhaps this all needs to be elaborated and summarized in the commit
> message.
> > Sidenote
> > Personally I'd wait for Mario for further info: after all it's him the
> > maintainer for AMD side and surely knows more than me.
> 
> Sure, I am with you on this.
>

What I'm saying below is purely based on my own speculations but it's the
most plausible thing I can think as for now.

When I tested Mario's patch back in April it totally used to work on my 
device: I have an idea that the value probably happened to be equal 1, like 
requested on the patch and making it working as intended.

In the meantime I updated the BIOS (from 310 to 315, released in May),
changing the value from 1 to 0 and breaking the boot time again (as said it's 
my own speculation, I'm not sure if it is actually possible).

I didn't test the patch after the BIOS update 'cause I had the
gpiolib_acpi.run_edge_events_on_boot=0 option enabled and didn't think it 
would stop working again.

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Marco Scardovi]

> 
> Okay, perhaps this all needs to be elaborated and summarized in the commit
> message.
> > Sidenote
> > Personally I'd wait for Mario for further info: after all it's him the
> > maintainer for AMD side and surely knows more than me.
> 
> Sure, I am with you on this.
>

What I'm saying below is purely based on my own speculations but it's the
most plausible thing I can think as for now.

When I tested Mario's patch back in April it totally used to work on my 
device: I have an idea that the value probably happened to be equal 1, like 
requested on the patch and making it working as intended.

In the meantime I updated the BIOS (from 310 to 315, released in May),
changing the value from 1 to 0 and breaking the boot time again (as said it's 
my own speculation, I'm not sure if it is actually possible).

I didn't test the patch after the BIOS update 'cause I had the
gpiolib_acpi.run_edge_events_on_boot=0 option enabled and didn't think it 
would stop working again.

Re: [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series

[Basavaraj Natikar]

hi,

On 6/16/2026 2:38 PM, Marco Scardovi wrote:
> The ASUS ROG Strix G16 G614 series laptops experience a long boot delay of
> approximately 36 seconds. This happens because the system firmware triggers
> a slow/hanging ActiveBoth GPIO interrupt handler at boot time.
>
> Even though commit 3bb62e3f99a5 ("gpiolib: acpi: Only trigger ActiveBoth
> interrupts on boot") restricted boot-time execution to ActiveBoth edge
> events, the problematic interrupt on these laptops is configured as
> ActiveBoth. Consequently, the handler is still executed at boot and
> the boot process stalls.
>
> Fix the delay by adding a DMI quirk to disable edge event execution at
> boot for the ASUS ROG Strix G16 G614 family.

Could you reword the commit message to explain the actual mechanism?
Something like:

On ASUS ROG Strix G16 G614 series laptops, the firmware leaves this
ActiveBoth GPIO line asserted (logic low) at boot. Per the boot-time
initial-state logic, an ActiveBoth interrupt found low is replayed
once to sync its initial state, which calls the handler synchronously
in the probe path. On these laptops that interrupt handler is slow/hanging,
so the synchronous call blocks for ~36 s and stalls boot.

It's also worth noting that commit 3bb62e3f99a5 already restricts the
boot-time replay to ActiveBoth interrupts that are asserted (low) — the pin
on ASUS ROG Strix G16 G614 series laptops meets exactly that condition,
which is why it still triggers. Disabling edge_events_on_boot via the
DMI quirk is therefore the right workaround for these laptops.

Thanks,
--
Basavaraj

>
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Marco Scardovi <scardracs@disroot.org>
> ---
>   drivers/gpio/gpiolib-acpi-quirks.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
> index a0116f004975..fa0f03bd51af 100644
> --- a/drivers/gpio/gpiolib-acpi-quirks.c
> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
> @@ -392,6 +392,20 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>   			.ignore_wake = "VEN_0488:00@355",
>   		},
>   	},
> +	{
> +		/*
> +		 * ASUS ROG Strix G614 series laptops experience a long boot
> +		 * delay (approx. 36 seconds) due to a slow/hanging ActiveBoth
> +		 * GPIO interrupt handler executing at boot.
> +		 */
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.no_edge_events_on_boot = true,
> +		},
> +	},
>   	{} /* Terminating entry */
>   };
>   

[PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

Hi Basavaraj,

Thank you for your review: this is the v2 with the rewording as requested.

Changes in v2:
- Reworded the commit message and the code comment to explain the actual
  boot-time replay mechanism as suggested by Basavaraj.
- Explicitly noted that the touchpad itself is driven by i2c-hid and functions
  normally, and that the ACPI event handler is preserved for post-boot events.
- Rebased against linux-next-20260616

Marco Scardovi (1):
  gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

 drivers/gpio/gpiolib-acpi-quirks.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.54.0

[PATCH v2 1/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

ASUS ROG Strix G16 G614 series laptops experience a long boot delay of
approximately 36 seconds.

On these laptops, the firmware leaves the touchpad's ActiveBoth GPIO
line asserted (logic low) at boot. Per the boot-time initial-state logic,
an ActiveBoth interrupt found low is replayed once to sync its initial state,
which calls the handler synchronously in the probe path. On these laptops
that interrupt handler is slow/hanging, so the synchronous call blocks for
~36s and stalls boot.

The touchpad itself is driven by the i2c-hid driver using a standard
GpioInt() resource defined in the touchpad device's _CRS method. The ACPI
event handler on pin 21 is distinct from this and is not required for the
touchpad's initialization or runtime operation.

Commit 3bb62e3f99a5 ("gpiolib: acpi: Only trigger ActiveBoth interrupts
on boot") restricted the boot-time replay to ActiveBoth interrupts that are
asserted (low). The pin on ASUS ROG Strix G16 G614 series laptops meets
exactly that condition, which is why it still triggers.

Fix the delay by adding a DMI quirk to set no_edge_events_on_boot to true
for the ASUS ROG Strix G16 G614 family. This prevents the boot-time
trigger of this ACPI event handler without affecting the touchpad driver
or disabling the handler for post-boot events.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 drivers/gpio/gpiolib-acpi-quirks.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index a0116f004975..3cd4cd27808a 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,6 +392,21 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
 			.ignore_wake = "VEN_0488:00@355",
 		},
 	},
+	{
+		/*
+		 * ASUS ROG Strix G16 G614 series laptops experience a long boot
+		 * delay (approx. 36 seconds) because the touchpad's ActiveBoth
+		 * GPIO interrupt handler (TP_ATTN#) stalls/hangs during boot
+		 * initialization.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16 G614"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.no_edge_events_on_boot = true,
+		},
+	},
 	{} /* Terminating entry */
 };
 
-- 
2.54.0

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Armin Wolf]

Am 17.06.26 um 20:50 schrieb Marco Scardovi:

> Hi Basavaraj,
>
> Thank you for your review: this is the v2 with the rewording as requested.

Hi,

could you share the output of "acpidump" on your device? I suspect that Asus
uses a _DSM control method to tell Windows to invert the polarity inside the
ActiveBoth check.

Thanks,
Armin Wolf

> Changes in v2:
> - Reworded the commit message and the code comment to explain the actual
>    boot-time replay mechanism as suggested by Basavaraj.
> - Explicitly noted that the touchpad itself is driven by i2c-hid and functions
>    normally, and that the ACPI event handler is preserved for post-boot events.
> - Rebased against linux-next-20260616
>
> Marco Scardovi (1):
>    gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
>
>   drivers/gpio/gpiolib-acpi-quirks.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

Hi Armin,

On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
>
> could you share the output of "acpidump" on your device? I suspect that Asus
> uses a _DSM control method to tell Windows to invert the polarity inside the
> ActiveBoth check.
>
I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from acpidump.
You can find the raw acpidump.out and the decompiled ASL tables in the
following Google Drive folder:
https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc?usp=drive_link

As far as I can see/understand there is no _DSM method defined under the
GPIO controller device (AMDI0030) or the \_SB.GPIO scope.

Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
pin 24 (0x18) are defined as:

GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
    "\\_SB.GPIO", 0x00, ResourceConsumer, ,
    )
    {
        0x0015 // Pin 21 (Touchpad attention line)
    }

When triggered, they evaluate the _EVT method which calls:
Case (0x15)
{
    \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
}

Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and ATKM/ADTM,
which stalls synchronously for ~36 seconds when executed during the probe path at 
boot time.

Thanks,
Marco

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Basavaraj Natikar]

hi


On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> [You don't often get email from scardracs@disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Armin,
>
> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
>> could you share the output of "acpidump" on your device? I suspect that Asus
>> uses a _DSM control method to tell Windows to invert the polarity inside the
>> ActiveBoth check.
>>
> I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from acpidump.
> You can find the raw acpidump.out and the decompiled ASL tables in the
> following Google Drive folder:
> https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc?usp=drive_link
>
> As far as I can see/understand there is no _DSM method defined under the
> GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
>
> Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> pin 24 (0x18) are defined as:
>
> GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
>      "\\_SB.GPIO", 0x00, ResourceConsumer, ,
>      )
>      {
>          0x0015 // Pin 21 (Touchpad attention line)
>      }
>
> When triggered, they evaluate the _EVT method which calls:
> Case (0x15)
> {
>      \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> }
>
> Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and ATKM/ADTM,
> which stalls synchronously for ~36 seconds when executed during the probe path at
> boot time.

I traced the _EVT for pin 21 through the dumps:

_EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the Else branch:
M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change" to the dGPU, then
ATKM(0xC0)/ADTM().

So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the touchpad —
the earlier "touchpad" characterization is incorrect. The touchpad
(TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in its _CRS on a
different line (pin 0x08, Level/ActiveLow).

The ~36 s stall is consistent with these synchronous MMIO reads + dGPU notify
\running in the boot probe path while the GPU isn't ready
(no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
confirm the exact blocking access).
Either way, running this AML synchronously at boot is the firmware issue
the no_edge_events_on_boot quirk works around.

Could you update the commit message accordingly — in particular, drop the
"touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not the touchpad?

Thanks,
--
Basavaraj

> Thanks,
> Marco

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Andy Shevchenko]

On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:

...

> > I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from acpidump.
> > You can find the raw acpidump.out and the decompiled ASL tables in the
> > following Google Drive folder:
> > https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc?usp=drive_link
> > 
> > As far as I can see/understand there is no _DSM method defined under the
> > GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
> > 
> > Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> > pin 24 (0x18) are defined as:
> > 
> > GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> >      "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> >      )
> >      {
> >          0x0015 // Pin 21 (Touchpad attention line)
> >      }
> > 
> > When triggered, they evaluate the _EVT method which calls:
> > Case (0x15)
> > {
> >      \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> > }
> > 
> > Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and ATKM/ADTM,
> > which stalls synchronously for ~36 seconds when executed during the probe path at
> > boot time.
> 
> I traced the _EVT for pin 21 through the dumps:
> 
> _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the Else branch:
> M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change" to the dGPU, then
> ATKM(0xC0)/ADTM().
> 
> So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the touchpad —
> the earlier "touchpad" characterization is incorrect. The touchpad
> (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in its _CRS on a
> different line (pin 0x08, Level/ActiveLow).
> 
> The ~36 s stall is consistent with these synchronous MMIO reads + dGPU notify
> \running in the boot probe path while the GPU isn't ready
> (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
> confirm the exact blocking access).
> Either way, running this AML synchronously at boot is the firmware issue
> the no_edge_events_on_boot quirk works around.
> 
> Could you update the commit message accordingly — in particular, drop the
> "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not the touchpad?

Thanks for the details! The crucial and most important question here, is AMD
going to push OEM(s) to fix firmware accordingly?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> > On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > > On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
> ...
> 
> > > I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from
> > > acpidump. You can find the raw acpidump.out and the decompiled ASL
> > > tables in the following Google Drive folder:
> > > https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc
> > > ?usp=drive_link
> > > 
> > > As far as I can see/understand there is no _DSM method defined under the
> > > GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
> > > 
> > > Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> > > pin 24 (0x18) are defined as:
> > > 
> > > GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> > > 
> > >      "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> > >      )
> > >      {
> > >      
> > >          0x0015 // Pin 21 (Touchpad attention line)
> > >      
> > >      }
> > > 
> > > When triggered, they evaluate the _EVT method which calls:
> > > Case (0x15)
> > > {
> > > 
> > >      \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> > > 
> > > }
> > > 
> > > Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and
> > > ATKM/ADTM, which stalls synchronously for ~36 seconds when executed
> > > during the probe path at boot time.
> > 
> > I traced the _EVT for pin 21 through the dumps:
> > 
> > _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the
> > Else branch: M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change"
> > to the dGPU, then ATKM(0xC0)/ADTM().

It seems I have much more to study about ACPI Tables. Sorry for the confusion
and thank you for checking it out.

> > 
> > So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the
> > touchpad — the earlier "touchpad" characterization is incorrect. The
> > touchpad (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in
> > its _CRS on a different line (pin 0x08, Level/ActiveLow).
> > 
> > The ~36 s stall is consistent with these synchronous MMIO reads + dGPU
> > notify \running in the boot probe path while the GPU isn't ready
> > (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
> > confirm the exact blocking access).
> > Either way, running this AML synchronously at boot is the firmware issue
> > the no_edge_events_on_boot quirk works around.
> > 
> > Could you update the commit message accordingly — in particular, drop the
> > "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not
> > the touchpad?

I'll do it. Let also me know for @Andy request below.

> Thanks for the details! The crucial and most important question here, is AMD
> going to push OEM(s) to fix firmware accordingly?

It seems ASUS released a new BIOS update 2 days ago specifically for my device.
You can find the new acpidump here:
https://drive.google.com/drive/folders/1PYmF1R9n-6vHJVSH8bzEPZhRgdmBBJlT?usp=sharing

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Andy Shevchenko]

On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> > On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> > > On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > > > On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:

...

> > > > I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from
> > > > acpidump. You can find the raw acpidump.out and the decompiled ASL
> > > > tables in the following Google Drive folder:
> > > > https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc
> > > > ?usp=drive_link
> > > > 
> > > > As far as I can see/understand there is no _DSM method defined under the
> > > > GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
> > > > 
> > > > Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> > > > pin 24 (0x18) are defined as:
> > > > 
> > > > GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> > > > 
> > > >      "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> > > >      )
> > > >      {
> > > >      
> > > >          0x0015 // Pin 21 (Touchpad attention line)
> > > >      
> > > >      }
> > > > 
> > > > When triggered, they evaluate the _EVT method which calls:
> > > > Case (0x15)
> > > > {
> > > > 
> > > >      \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> > > > 
> > > > }
> > > > 
> > > > Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and
> > > > ATKM/ADTM, which stalls synchronously for ~36 seconds when executed
> > > > during the probe path at boot time.
> > > 
> > > I traced the _EVT for pin 21 through the dumps:
> > > 
> > > _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the
> > > Else branch: M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change"
> > > to the dGPU, then ATKM(0xC0)/ADTM().
> 
> It seems I have much more to study about ACPI Tables. Sorry for the confusion
> and thank you for checking it out.
> 
> > > So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the
> > > touchpad — the earlier "touchpad" characterization is incorrect. The
> > > touchpad (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in
> > > its _CRS on a different line (pin 0x08, Level/ActiveLow).
> > > 
> > > The ~36 s stall is consistent with these synchronous MMIO reads + dGPU
> > > notify \running in the boot probe path while the GPU isn't ready
> > > (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
> > > confirm the exact blocking access).
> > > Either way, running this AML synchronously at boot is the firmware issue
> > > the no_edge_events_on_boot quirk works around.
> > > 
> > > Could you update the commit message accordingly — in particular, drop the
> > > "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not
> > > the touchpad?
> 
> I'll do it. Let also me know for @Andy request below.
> 
> > Thanks for the details! The crucial and most important question here, is AMD
> > going to push OEM(s) to fix firmware accordingly?
> 
> It seems ASUS released a new BIOS update 2 days ago specifically for my device.
> You can find the new acpidump here:
> https://drive.google.com/drive/folders/1PYmF1R9n-6vHJVSH8bzEPZhRgdmBBJlT?usp=sharing

Have you tried it already?

At least the DSDT has neither _AEI, nor ActiveBoth for anything (except speaker
device). Looks promising to me as a fixed version.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
> > On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> > > On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> > > > On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > > > > On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
> 
> ...
> 
> > > > > I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from
> > > > > acpidump. You can find the raw acpidump.out and the decompiled ASL
> > > > > tables in the following Google Drive folder:
> > > > > https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc
> > > > > ?usp=drive_link
> > > > > 
> > > > > As far as I can see/understand there is no _DSM method defined under the
> > > > > GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
> > > > > 
> > > > > Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> > > > > pin 24 (0x18) are defined as:
> > > > > 
> > > > > GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> > > > > 
> > > > >      "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> > > > >      )
> > > > >      {
> > > > >      
> > > > >          0x0015 // Pin 21 (Touchpad attention line)
> > > > >      
> > > > >      }
> > > > > 
> > > > > When triggered, they evaluate the _EVT method which calls:
> > > > > Case (0x15)
> > > > > {
> > > > > 
> > > > >      \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> > > > > 
> > > > > }
> > > > > 
> > > > > Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and
> > > > > ATKM/ADTM, which stalls synchronously for ~36 seconds when executed
> > > > > during the probe path at boot time.
> > > > 
> > > > I traced the _EVT for pin 21 through the dumps:
> > > > 
> > > > _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the
> > > > Else branch: M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change"
> > > > to the dGPU, then ATKM(0xC0)/ADTM().
> > 
> > It seems I have much more to study about ACPI Tables. Sorry for the confusion
> > and thank you for checking it out.
> > 
> > > > So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the
> > > > touchpad — the earlier "touchpad" characterization is incorrect. The
> > > > touchpad (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in
> > > > its _CRS on a different line (pin 0x08, Level/ActiveLow).
> > > > 
> > > > The ~36 s stall is consistent with these synchronous MMIO reads + dGPU
> > > > notify \running in the boot probe path while the GPU isn't ready
> > > > (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
> > > > confirm the exact blocking access).
> > > > Either way, running this AML synchronously at boot is the firmware issue
> > > > the no_edge_events_on_boot quirk works around.
> > > > 
> > > > Could you update the commit message accordingly — in particular, drop the
> > > > "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not
> > > > the touchpad?
> > 
> > I'll do it. Let also me know for @Andy request below.
> > 
> > > Thanks for the details! The crucial and most important question here, is AMD
> > > going to push OEM(s) to fix firmware accordingly?
> > 
> > It seems ASUS released a new BIOS update 2 days ago specifically for my device.
> > You can find the new acpidump here:
> > https://drive.google.com/drive/folders/1PYmF1R9n-6vHJVSH8bzEPZhRgdmBBJlT?usp=sharing
> 
> Have you tried it already?
> 
> At least the DSDT has neither _AEI, nor ActiveBoth for anything (except speaker
> device). Looks promising to me as a fixed version.
> 
Yes, it didn't solve the boot time problem

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Basavaraj Natikar]

On 6/18/2026 11:37 PM, Marco Scardovi wrote:
> In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
>> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
>>> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
>>>> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
>>>>> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
>>>>>> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
>> ...
>>
>>>>>> I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from
>>>>>> acpidump. You can find the raw acpidump.out and the decompiled ASL
>>>>>> tables in the following Google Drive folder:
>>>>>> https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc
>>>>>> ?usp=drive_link
>>>>>>
>>>>>> As far as I can see/understand there is no _DSM method defined under the
>>>>>> GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
>>>>>>
>>>>>> Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
>>>>>> pin 24 (0x18) are defined as:
>>>>>>
>>>>>> GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
>>>>>>
>>>>>>       "\\_SB.GPIO", 0x00, ResourceConsumer, ,
>>>>>>       )
>>>>>>       {
>>>>>>       
>>>>>>           0x0015 // Pin 21 (Touchpad attention line)
>>>>>>       
>>>>>>       }
>>>>>>
>>>>>> When triggered, they evaluate the _EVT method which calls:
>>>>>> Case (0x15)
>>>>>> {
>>>>>>
>>>>>>       \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
>>>>>>
>>>>>> }
>>>>>>
>>>>>> Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and
>>>>>> ATKM/ADTM, which stalls synchronously for ~36 seconds when executed
>>>>>> during the probe path at boot time.
>>>>> I traced the _EVT for pin 21 through the dumps:
>>>>>
>>>>> _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the
>>>>> Else branch: M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change"
>>>>> to the dGPU, then ATKM(0xC0)/ADTM().
>>> It seems I have much more to study about ACPI Tables. Sorry for the confusion
>>> and thank you for checking it out.
>>>
>>>>> So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the
>>>>> touchpad — the earlier "touchpad" characterization is incorrect. The
>>>>> touchpad (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in
>>>>> its _CRS on a different line (pin 0x08, Level/ActiveLow).
>>>>>
>>>>> The ~36 s stall is consistent with these synchronous MMIO reads + dGPU
>>>>> notify \running in the boot probe path while the GPU isn't ready
>>>>> (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
>>>>> confirm the exact blocking access).
>>>>> Either way, running this AML synchronously at boot is the firmware issue
>>>>> the no_edge_events_on_boot quirk works around.
>>>>>
>>>>> Could you update the commit message accordingly — in particular, drop the
>>>>> "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not
>>>>> the touchpad?
>>> I'll do it. Let also me know for @Andy request below.
>>>
>>>> Thanks for the details! The crucial and most important question here, is AMD
>>>> going to push OEM(s) to fix firmware accordingly?
>>> It seems ASUS released a new BIOS update 2 days ago specifically for my device.
>>> You can find the new acpidump here:
>>> https://drive.google.com/drive/folders/1PYmF1R9n-6vHJVSH8bzEPZhRgdmBBJlT?usp=sharing
>> Have you tried it already?
>>
>> At least the DSDT has neither _AEI, nor ActiveBoth for anything (except speaker
>> device). Looks promising to me as a fixed version.
>>
> Yes, it didn't solve the boot time problem
>
>
I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.

On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
this behavior and follow up on a firmware fix.

Thanks,
--
Basavaraj

>

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

In data venerdì 19 giugno 2026 12:17:17 Ora legale dell’Europa centrale, Basavaraj Natikar ha scritto:
> On 6/18/2026 11:37 PM, Marco Scardovi wrote:
> > In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
> >> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
> >>> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> >>>> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> >>>>> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> >>>>>> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
...
> 
> I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
> to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.
> 
> On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
> this behavior and follow up on a firmware fix.
> 
> Thanks,
> --
> Basavaraj
> 
Hi Basavaraj,

Thank you. Does that mean that my patch will not be required anymore?
If that's the case you can consider it as null. I don't mind having the boot
flag added until it's completely fixed on ASUS' side. BTW I have the suspect
that my model is not the only one with the long boot bug on ASUS [1] [2]
but actually the only one who came up with an actual patch on the kernel.

[1] https://bbs.archlinux.org/viewtopic.php?id=307251
[2] https://rog-forum.asus.com/t5/rog-strix-series/linux-boot-is-very-slow-at-this-moment/td-p/1138746

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Andy Shevchenko]

On Fri, Jun 19, 2026 at 12:28:49PM +0200, Marco Scardovi wrote:
> In data venerdì 19 giugno 2026 12:17:17 Ora legale dell’Europa centrale, Basavaraj Natikar ha scritto:
> > On 6/18/2026 11:37 PM, Marco Scardovi wrote:
> > > In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
> > >> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
> > >>> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> > >>>> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> > >>>>> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > >>>>>> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:

...

> > I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
> > to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.
> > 
> > On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
> > this behavior and follow up on a firmware fix.
> 
> Thank you. Does that mean that my patch will not be required anymore?
> If that's the case you can consider it as null. I don't mind having the boot
> flag added until it's completely fixed on ASUS' side. BTW I have the suspect
> that my model is not the only one with the long boot bug on ASUS [1] [2]
> but actually the only one who came up with an actual patch on the kernel.

I believe your patch is still needed. Not every model might get a BIOS update,
and no guarantee that everybody who possesses the problematic platforms
actually *will* update the BIOS. But it's AMD's call. I will happily accept
the changes acknowledged by AMD.

> [1] https://bbs.archlinux.org/viewtopic.php?id=307251
> [2] https://rog-forum.asus.com/t5/rog-strix-series/linux-boot-is-very-slow-at-this-moment/td-p/1138746

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

In data sabato 20 giugno 2026 08:52:27 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
> On Fri, Jun 19, 2026 at 12:28:49PM +0200, Marco Scardovi wrote:
> > In data venerdì 19 giugno 2026 12:17:17 Ora legale dell’Europa centrale, Basavaraj Natikar ha scritto:
> > > On 6/18/2026 11:37 PM, Marco Scardovi wrote:
> > > > In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
> > > >> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
> > > >>> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
> > > >>>> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> > > >>>>> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > > >>>>>> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
> 
> ...
> 
> > > I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
> > > to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.
> > > 
> > > On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
> > > this behavior and follow up on a firmware fix.
> > 
> > Thank you. Does that mean that my patch will not be required anymore?
> > If that's the case you can consider it as null. I don't mind having the boot
> > flag added until it's completely fixed on ASUS' side. BTW I have the suspect
> > that my model is not the only one with the long boot bug on ASUS [1] [2]
> > but actually the only one who came up with an actual patch on the kernel.
> 
> I believe your patch is still needed. Not every model might get a BIOS update,
> and no guarantee that everybody who possesses the problematic platforms
> actually *will* update the BIOS. But it's AMD's call. I will happily accept
> the changes acknowledged by AMD.
>
Uhm, right. Not everyone are crazy over updating everything.

As soon as I have a complete response from AMD and Asus I'll proceed
with a proper patch.

For now, thank you all for checking it out and giving your time for feedback.
> 
> > [1] https://bbs.archlinux.org/viewtopic.php?id=307251
> > [2] https://rog-forum.asus.com/t5/rog-strix-series/linux-boot-is-very-slow-at-this-moment/td-p/1138746
> 
> 

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Mario Limonciello]

On 6/20/26 00:20, Marco Scardovi wrote:
> In data sabato 20 giugno 2026 08:52:27 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
>> On Fri, Jun 19, 2026 at 12:28:49PM +0200, Marco Scardovi wrote:
>>> In data venerdì 19 giugno 2026 12:17:17 Ora legale dell’Europa centrale, Basavaraj Natikar ha scritto:
>>>> On 6/18/2026 11:37 PM, Marco Scardovi wrote:
>>>>> In data giovedì 18 giugno 2026 20:01:40 Ora legale dell’Europa centrale, Andy Shevchenko ha scritto:
>>>>>> On Thu, Jun 18, 2026 at 06:59:15PM +0200, Marco Scardovi wrote:
>>>>>>> On Thu, Jun 18, 2026 at 16:35:37 CEST, Andy Shevchenko wrote:
>>>>>>>> On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
>>>>>>>>> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
>>>>>>>>>> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
>>
>> ...
>>
>>>> I also checked the BIOS 316 ACPI dump — the stalling path is byte‑for‑byte identical
>>>> to 315, so the AML is unchanged and it'll still stall if pin 21 boots low.
>>>>
>>>> On the OEM side, I'm connecting internally with our AMD contact for ASUS to report
>>>> this behavior and follow up on a firmware fix.
>>>
>>> Thank you. Does that mean that my patch will not be required anymore?
>>> If that's the case you can consider it as null. I don't mind having the boot
>>> flag added until it's completely fixed on ASUS' side. BTW I have the suspect
>>> that my model is not the only one with the long boot bug on ASUS [1] [2]
>>> but actually the only one who came up with an actual patch on the kernel.
>>
>> I believe your patch is still needed. Not every model might get a BIOS update,
>> and no guarantee that everybody who possesses the problematic platforms
>> actually *will* update the BIOS. But it's AMD's call. I will happily accept
>> the changes acknowledged by AMD.
>>
> Uhm, right. Not everyone are crazy over updating everything.
> 
> As soon as I have a complete response from AMD and Asus I'll proceed
> with a proper patch.
> 
> For now, thank you all for checking it out and giving your time for feedback.

Maybe it's clear to everyone else but me; but if this is ASL used for 
the dGPU shouldn't we get someone from NVIDIA to add their 2¢?

Maybe *they* had intended this to be both edge triggered and that's how 
it got here.

I can't imagine this is going to be the only case we see of this.  So 
before we go down that quirk path can we get them to weigh in?  Maybe 
send to dri-devel and CC the nvidia folks that work on the kernel.

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Hans de Goede]

Hi Marco,

On 17-Jun-26 20:50, Marco Scardovi wrote:
> Hi Basavaraj,
> 
> Thank you for your review: this is the v2 with the rewording as requested.
> 
> Changes in v2:
> - Reworded the commit message and the code comment to explain the actual
>   boot-time replay mechanism as suggested by Basavaraj.
> - Explicitly noted that the touchpad itself is driven by i2c-hid and functions
>   normally, and that the ACPI event handler is preserved for post-boot events.
> - Rebased against linux-next-20260616
> 
> Marco Scardovi (1):
>   gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

Have you tried adding this patch to your kernel instead of adding a quirk? :

https://lore.kernel.org/linux-gpio/20260429025247.1372984-1-mario.limonciello@amd.com/

This modifies the code which does an initial sync of edge-run ACPI GPIO
interrupt event handlers to match Windows and to skip it in certain
circumstances.

If that does not help, we should wait for Armin to get a chance to check
your DSDT to see if the magic _DSM which inverts the polarity check for
the initial sync run is there.

By matching what Windows this we can hopefully fix this for a whole bunch
of devices rather then having to rely on per model quirks.

Regards,

Hans

Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series

[Marco Scardovi]

In data domenica 21 giugno 2026 13:00:22 Ora legale dell’Europa centrale, Hans de Goede ha scritto:
> Hi Marco,
> 
> On 17-Jun-26 20:50, Marco Scardovi wrote:
> > Hi Basavaraj,
> > 
> > Thank you for your review: this is the v2 with the rewording as requested.
> > 
> > Changes in v2:
> > - Reworded the commit message and the code comment to explain the actual
> >   boot-time replay mechanism as suggested by Basavaraj.
> > - Explicitly noted that the touchpad itself is driven by i2c-hid and functions
> >   normally, and that the ACPI event handler is preserved for post-boot events.
> > - Rebased against linux-next-20260616
> > 
> > Marco Scardovi (1):
> >   gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
> 
> Have you tried adding this patch to your kernel instead of adding a quirk? :
> 
> https://lore.kernel.org/linux-gpio/20260429025247.1372984-1-mario.limonciello@amd.com/
> 
Yes, in fact it used to work [1]. My suspect is that when updating the BIOS
from 310 to 315 something flipped, making it not working again.
It's my own speculation so please don't take it as a matter of fact.

[1] https://lore.kernel.org/linux-gpio/a42767b8-7a0c-4202-9132-be8fa65baabc@gmail.com/
>
> This modifies the code which does an initial sync of edge-run ACPI GPIO
> interrupt event handlers to match Windows and to skip it in certain
> circumstances.
> 
> If that does not help, we should wait for Armin to get a chance to check
> your DSDT to see if the magic _DSM which inverts the polarity check for
> the initial sync run is there.
> 
> By matching what Windows this we can hopefully fix this for a whole bunch
> of devices rather then having to rely on per model quirks.
>
It would be very helpful as I noticed all these ASUS laptops in G614 family
ha the same problem as mine [2].

[2] https://github.com/OpenGamingCollective/asusctl/issues/115
> 
> Regards,
> 
> Hans
> 
Thank you all for looking into it,

Marco