On Sat, Mar 8, 2014 at 10:15 AM, Thomas Gleixner <[email protected]> wrote:
> On Fri, 7 Mar 2014, Linus Walleij wrote: >> I'll see what Jean-Jacques comes up with and take it from there unless >> he's interested in taking it all the way. > > Thought more about it while trying to come up with a persuasive > argument for the other Linus to take the irq_startup change that late > in the cycle: > > Using startup is the wrong point in __setup_irq() because we call > chip->irq_set_type() before we call chip->irq_startup(). And we want > this to be in that order to avoid spurious interrupts. > > Proper solution below. That leaves the startup/unmask logic untouched > and provides separate callbacks for this kind of requirements. That > makes it also simpler to have common functions for all gpios as you > don't have to do the mask/unmask dance in startup/shutdown. So you can > simply create gpio_irq_request/release_resources() and let the drivers > add those to their callbacks. > > If you agree, I put that into a separate branch based on an upstream > -rc so you can pull it into your gpiolib stuff and work from there. Yeah I really like the looks of this! Reviewed-by: Linus Walleij <[email protected]> We need to think about whether the gpiolib changes are serious enough to be pushed this late in the -rc cycle though. The thing is that the flagging of GPIO lines as IRQs was to fix up the ages-old mess of sequential semantic dependencies between different unrelated gpiolib and irqchip calls, and these bugs have been around since the first irqchip was implemented in drivers/gpio I think :-( But if you prefer, I'll surely do it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
