Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij
Date: Tue Aug 20 2019 - 03:12:20 EST
On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
> The proper fix is to revert the culprit since we call
> acpi_gpiochip_request_interrupts() for all controllers.
> Linus, please re-do the approach with IRQ handling,
Exactly what do you refer to when you want me to
"re-do the approach for IRQ handling"? Do you mean
this driver or are you referring to:
Author: Thierry Reding <treding@xxxxxxxxxx>
Date: Tue Nov 7 19:15:54 2017 +0100
gpio: Implement tighter IRQ chip integration
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
Acked-by: Grygorii Strashko <grygorii.strashko@xxxxxx>
Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
The new API introduced by this patch is what I am trying to switch
everything over to, because the forked paths inside of gpiolib
is causing me a maintenance headache and also increasing
the footprint of the library.
> it seems broadly
> regress with ACPI enabled platforms.
It only becomes a problem if the platform uses ACPI right?
But it's a problem if I can't really tell if a driver is using
ACPI or not, there is no sign in the pl061 driver that it would
be used on ACPI systems until now, so how do I design
The problem comes from the problem/mess I am trying to
clean up in the first place. So if the new way of registering GPIO
irqchips is not working for ACPI, then we have to fix that instead
of reverting all attempts to use the new API IMO.