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

[Armin Wolf <W_Armin@gmx.de>]

Am 25.04.26 um 17:15 schrieb Mario Limonciello:

> On 4/24/26 15:02, Armin Wolf wrote:
>> Am 23.04.26 um 19:46 schrieb Marco Scardovi:
>>
>>>
>>> On 4/23/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?
>>>>
>>> I see. Well, that makes totally sense 
>>
>> Hi,
>>
>> according to the Microsoft documentation 
>> (https://learn.microsoft.com/ 
>> en-us/windows-hardware/drivers/bringup/general-purpose-i-o--gpio-,
>> section "GPIO controllers and ActiveBoth interrupts"), triggering 
>> GPIO interrupts marked as ActiveBoth during initialization is
>> correct as long as the associated GPIO line is already "asserted" 
>> (aka logic level low). I think the problem is that we also trigger
>> edge-based GPIO interrupts _not_ marked as ActiveBoth.
>>
>> Based on this i agree with Hans, except that we should continue you 
>> trigger ActiveBoth GPIO interrupts as long as the above
>> condition applies.
>>
>> Thanks,
>> Armin Wolf
>>
>
> So maybe something like this (attached)?

Yes, exactly.

Thanks,
Armin Wolf