[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbRZ=88+ooW5jb5vu4Dwsaj7Ce+V5Ked2-bGn0JWpTHfQ@mail.gmail.com>
Date: Tue, 20 Aug 2019 09:12:04 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Thierry Reding <treding@...dia.com>
Cc: Wei Xu <xuwei5@...ilicon.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Linuxarm <linuxarm@...wei.com>,
Shameerali Kolothum Thodi
<shameerali.kolothum.thodi@...wei.com>,
Jonathan Cameron <jonathan.cameron@...wei.com>,
John Garry <john.garry@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>,
Shiju Jose <shiju.jose@...wei.com>, jinying@...ilicon.com,
Zhangyi ac <zhangyi.ac@...wei.com>,
"Liguozhu (Kenneth)" <liguozhu@...ilicon.com>,
Tangkunshan <tangkunshan@...wei.com>,
huangdaode <huangdaode@...ilicon.com>
Subject: Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
<andy.shevchenko@...il.com> 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@...dia.com>
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@...dia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@...com>
Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
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
Powered by blists - more mailing lists