Re: [PATCH 2/2] ACPI: AC: Add sleep quirk for ASUS ROG Flow X13 GV301Q

[Rafael J. Wysocki (Intel)]

On Sun, Nov 1, 2026 at 2:47 PM Hugo Sales <hugo@xxxxxxx> wrote:
>
> On a plug-in, this laptop's EC handler notifies AC0 once, before the
> adapter status bit that _PSR reads is set. The driver reports the
> adapter offline and no second notify follows, so user space that
> switches power profiles on the AC uevent, such as asusd, stays on its
> battery settings. Unplugging is not affected
>
> Add the machine to ac_dmi_table with ac_sleep_quirk(), the 1s delay
> already used for the ThinkPad E530
>
> Signed-off-by: Hugo Sales <hugo@xxxxxxx>
> ---
> The EC's plug-in handler, from iasl, without the EC locking and the
> ASUS WMI event calls, and with its two sleeps merged:
>
>  Method (_QA0, 0, NotSerialized)
>  {
>      If (ACPS ()) { ACPF = One } Else { ACPF = Zero }
>      Notify (AC0, 0x80)
>      Sleep (0x6E)
>      NBAT (0x80)
>  }
>
> ACPS() returns bit 0 of an EC status register, and _PSR reads the same
> bit. Polling the online attribute put the change 392ms after the
> uevent. The battery handler _QA3 notifies AC0 too on some paths, which
> hid the quirk now and then. On an unplug the bit is already clear when
> _QA0 runs, so the notify reports the right state
>
> With the quirk, both plug-in and unplug events reach user space 1s
> later, with the right state
>
> The delay runs in the notify handler on kacpi_notify_wq, as it does on
> the E530. acpi_s2idle_wake() flushes that queue after dispatching the
> EC GPE, so an AC event during s2idle keeps the CPU out of idle for up
> to 1s, and a suspend or resume right after an AC event can take up to
> 1s longer
>
> Tested on a GV301QH (BIOS 418). The match covers every product name
> containing "ROG Flow X13 GV301Q", which includes the 2021 GV301QC and
> GV301QE: a public DSDT dump of the GV301QE (BIOS 413) has the same _QA0,
> ACPS() and AC0._PSR line for line [1]. I found no table dump for the
> GV301QC, but a GV301QH board has been seen labelled "gv301qc", so they
> appear to share it. The 2022 GV301R and the later GV302 have different
> product names, so the quirk doesn't apply to them
>
> [1] https://github.com/andrewrabert/asus-flow-x13-linux/tree/main/dsdt
> ---
>  drivers/acpi/ac.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
> index 1cd7482bc0246..b014028555de9 100644
> --- a/drivers/acpi/ac.c
> +++ b/drivers/acpi/ac.c
> @@ -172,6 +172,18 @@ static int __init ac_only_quirk(const struct dmi_system_id *d)
>
>  /* Please keep this list alphabetically sorted */
>  static const struct dmi_system_id ac_dmi_table[]  __initconst = {
> +       {
> +               /*
> +                * ASUS ROG Flow X13 GV301Q notifies AC on a plug-in about 400ms
> +                * before _PSR reports it online. Seen on the GV301QH, and the
> +                * GV301QE runs the same EC handler
> +                */
> +               .callback = ac_sleep_quirk,
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "ROG Flow X13 GV301Q"),
> +               },
> +       },
>         {
>                 /* Kodlix GK45 returning incorrect state */
>                 .callback = ac_only_quirk,
> --

Applied along with the [1/2] as 7.5 material, thanks!