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

From: Andy Shevchenko

Date: Thu Jun 18 2026 - 10:36:33 EST


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