On Sat, Feb 18, 2023 at 11:32:33AM +0100, Hans de Goede wrote:
> x86 ACPI boards which ship with only Android as their factory image usually
> have pretty broken ACPI tables, relying on everything being hardcoded in
> the factory kernel image and often disabling parts of the ACPI enumeration
> kernel code to avoid the broken tables causing issues.
>
> Part of this broken ACPI code is that sometimes these boards have _AEI
> ACPI GPIO event handlers which are broken.
>
> So far this has been dealt with in the platform/x86/x86-android-tablets.c
> module, which contains various workarounds for these devices, by it calling
> acpi_gpiochip_free_interrupts() on gpiochip-s with troublesome handlers to
> disable the handlers.
>
> But in some cases this is too late, if the handlers are of the edge type
> then gpiolib-acpi.c's code will already have run them at boot.
> This can cause issues such as GPIOs ending up as owned by "ACPI:OpRegion",
> making them unavailable for drivers which actually need them.
>
> Boards with these broken ACPI tables are already listed in
> drivers/acpi/x86/utils.c for e.g. acpi_quirk_skip_i2c_client_enumeration().
> Extend the quirks mechanism for a new acpi_quirk_skip_gpio_event_handlers()
> helper, this re-uses the DMI-ids rather then having to duplicate the same
> DMI table in gpiolib-acpi.c .
>
> Also add the new ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS quirk to existing
> boards with troublesome ACPI gpio event handlers, so that the current
> acpi_gpiochip_free_interrupts() hack can be removed from
> x86-android-tablets.c .
I'm wondering if we can teach acpi_gpio_in_ignore_list() to handle this.
P.S. Why do we lock an IRQ before checking acpi_gpio_in_ignore_list() and
why do we not free that if the IRQ is in ignore list?
--
With Best Regards,
Andy Shevchenko
