On Tue, Aug 20, 2019 at 10:51 AM Andy Shevchenko <[email protected]> wrote: > On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <[email protected]> > wrote: > > On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko > > <[email protected]> wrote:
> > 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 <[email protected]> > > 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 <[email protected]> > > Acked-by: Grygorii Strashko <[email protected]> > > Signed-off-by: Linus Walleij <[email protected]> > > Yes. OK let's fix this mess, it shouldn't be too hard, I've sent a first few patches. > > 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. Sorry if I sounded harsh :( I just have a bit of panic. I am sure we can fix this, I only recently realized what a headache the new API is going to be if I can't straighten it out and have to keep the old stuff around forever in parallel. Yours, Linus Walleij
