Re: [BUG] 36-second boot delay due to by acpi_gpio_handle_deferred_request_irqs on ASUS ROG Strix G16 (2025)

[Hans de Goede <hansg@kernel.org>]

Hi,

On 27-Apr-26 14:41, Marco Scardovi wrote:
> 
> Il 27/04/26 14:28, Mika Westerberg ha scritto:
>> On Mon, Apr 27, 2026 at 01:46:03PM +0200, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 23-Apr-26 07:15, Mario Limonciello wrote:
>>>> On 4/22/26 23:42, Mika Westerberg wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Apr 22, 2026 at 02:08:29PM +0200, Marco Scardovi wrote:
>>>>>>>> Assuming all the variants suffer the same problem would it be ok to use a
>>>>>>>> wildcard for it?
>>>>>>> Yeah, we could expand it to all "ROG Strix G16" I think:
>>>>>>>
>>>>>>> diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
>>>>>>> index a0116f004975..e3a6111854e8 100644
>>>>>>> --- a/drivers/gpio/gpiolib-acpi-quirks.c
>>>>>>> +++ b/drivers/gpio/gpiolib-acpi-quirks.c
>>>>>>> @@ -392,6 +392,23 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
>>>>>>>                 .ignore_wake = "VEN_0488:00@355",
>>>>>>>             },
>>>>>>>         },
>>>>>>> +    {
>>>>>>> +        /*
>>>>>>> +         * The ASUS ROG Strix G16 (2025) ACPI GPIO configuration
>>>>>>> +         * causes acpi_gpio_handle_deferred_request_irqs() to
>>>>>>> +         * stall for ~36 seconds during boot so ignore the two
>>>>>>> +         * interrupts involved.
>>>>>>> +         *
>>>>>>> +         * Found in BIOS G614PP.307.
>>>>>>> +         */
>>>>>>> +        .matches = {
>>>>>>> +            DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>>>>>> +            DMI_MATCH(DMI_PRODUCT_NAME, "ROG Strix G16"),
>>>>>>> +        },
>>>>>>> +        .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
>>>>>>> +            .ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
>>>>>>> +        },
>>>>>>> +    },
>>>>>>>         {} /* Terminating entry */
>>>>>>>     };
>>>>>> As for now it seems working. I've reverted it on my kernel as I prefer
>>>>>> remain as much as possible close to the CachyOS' one but hopefully it will
>>>>>> be implemented on 7.1, if someone propose the patch and it is accepted. It
>>>>>> would be amazing to see Asus more interested on Linux and more strict with
>>>>>> their BIOS but in the end I understand it's like asking for the moon.
>>>>> Okay thanks for checking. I guess this is what we have to live with for now
>>>>> until someone finds a better way of dealing with these.
>>>>>
>>>>> @Francesco, would you like to submit a new version of the patch similar to
>>>>> above or you want me to do that?
>>>> Hans suggested that we might want to look at ripping out this edge triggered events at boot earlier in the thread.
>>>>
>>>> https://lore.kernel.org/platform-driver-x86/20260423044211.GD557136@black.igk.intel.com/T/#mdca882e6606d3a894ec7499d3b742d040933dbdb
>>>>
>>>> Hans - as you pointed out that the Surface lid state is the only real issue left and you happen to have one do you think you could work up some patches?
>>> Right, so I read further in the thread that Armin has a maybe better suggestion,
>>> after that has been merged I can check a bunch of the current devices with
>>> .no_edge_events_on_boot which I still have and see if those quirks can be
>>> dropped now.
>>>
>>> But the above quirk for the ASUS ROG Strix G16 (2025) does not use
>>> .no_edge_events_on_boot which just disables the initial run of
>>> the ACPI event handler at boot. Instead it uses:
>>>
>>>              .ignore_interrupt = "AMDI0030:00@21,AMDI0030:00@24",
>>>
>>> which *completely* disables the ACPI event handlers for the mentioned pins.
>> Oh, I've completely lost track of all the quirks that were added after I
>> did anything with the ACPI GPIO stuff :(. Sorry about missing this. I will
>> stay silent from now on ;-)
> 
> Hi Everyone,
> 
> @hans, I tried it and can confirm it does the trick as well.

Great, that is good news.

Thank you for testing.

Can you try Mario's patch from:

https://lore.kernel.org/platform-driver-x86/f4979d43-f61f-4387-8490-ccec7043c940@kernel.org/

That changes the run-edge-events-at-boot behavior to only run
under the same conditions as it does under Windows (according to
the Windows docs). So maybe that will fix things without needing
a quirk ?

If you give this a test please remember to remove any other
workarounds like the kernel commandline option.

Regards,

Hans