[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcwDZdOwFsT4Gf-1a4tNGQdowK-RKRvSif2m7oTsVQNbw@mail.gmail.com>
Date: Tue, 20 Aug 2019 11:51:01 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Thierry Reding <treding@...dia.com>, 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 Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <linus.walleij@...aro.org> wrote:
> 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>
Yes.
> 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.
Yes, I understand.
> > it seems broadly
> > regress with ACPI enabled platforms.
>
> It only becomes a problem if the platform uses ACPI right?
Unfortunately yes. Though in this case it was working and stopped working.
> 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?
It's hidden under amba_driver_register() which works for all
registered thru drivers/acpi/acpi_amba.c.
I agree this is not straightforward.
> 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.
Sorry for me being impatient and asking for a groundless requests.
I'll help you with cleaning this.
--
With Best Regards,
Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists