From: Marco Scardovi <scardracs@disroot.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Basavaraj Natikar <bnatikar@amd.com>,
w_armin@gmx.de, brgl@kernel.org, linusw@kernel.org,
linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, mario.limonciello@amd.com,
westeri@kernel.org
Subject: Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
Date: Thu, 18 Jun 2026 20:07:11 +0200 [thread overview]
Message-ID: <_tDfR2zvSRyshOH99j8NCA@disroot.org> (raw)
In-Reply-To: <ajQyhOuvripaiXEq@ashevche-desk.local>
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
next prev parent reply other threads:[~2026-06-18 18:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 9:08 [PATCH] gpiolib: acpi: Add quirk for ASUS ROG Strix G614 series Marco Scardovi
2026-06-16 9:31 ` Andy Shevchenko
2026-06-16 9:43 ` Marco Scardovi
2026-06-16 9:58 ` Andy Shevchenko
2026-06-16 10:24 ` Mika Westerberg
2026-06-16 10:58 ` Marco Scardovi
2026-06-16 11:04 ` Andy Shevchenko
2026-06-17 8:51 ` Marco Scardovi
2026-06-17 8:52 ` Marco Scardovi
2026-06-17 18:34 ` Basavaraj Natikar
2026-06-17 18:50 ` [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 " Marco Scardovi
2026-06-17 18:50 ` [PATCH v2 1/1] " Marco Scardovi
2026-06-17 21:23 ` [PATCH v2 0/1] " Armin Wolf
2026-06-17 23:14 ` Marco Scardovi
2026-06-18 13:16 ` Basavaraj Natikar
2026-06-18 14:35 ` Andy Shevchenko
2026-06-18 16:59 ` Marco Scardovi
2026-06-18 18:01 ` Andy Shevchenko
2026-06-18 18:07 ` Marco Scardovi [this message]
2026-06-19 10:17 ` Basavaraj Natikar
2026-06-19 10:28 ` Marco Scardovi
2026-06-20 6:52 ` Andy Shevchenko
2026-06-20 7:20 ` Marco Scardovi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=_tDfR2zvSRyshOH99j8NCA@disroot.org \
--to=scardracs@disroot.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bnatikar@amd.com \
--cc=brgl@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=w_armin@gmx.de \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox