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 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