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

[Basavaraj Natikar <bnatikar@amd.com>]

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

>