On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij [off-list ref] wrote:

On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
[off-list ref] wrote:

quoted

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 [off-list ref]
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 [off-list ref]
    Acked-by: Grygorii Strashko [off-list ref]
    Signed-off-by: Linus Walleij [off-list ref]

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.

quoted

 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

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel