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