Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:

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

commit e0d89728981393b7d694bd3419b7794b9882c92d
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
for it?

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.

Yours,
Linus Walleij