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

[Basavaraj Natikar <bnatikar@amd.com>]

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