[PATCH] irq: Consider a negative return value of irq_startup() as an error

Linus Walleij
2014-03-12T14:49:39Z

On Sat, Mar 8, 2014 at 10:15 AM, Thomas Gleixner <tglx@linutronix.de> 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 <linus.walleij@linaro.org>

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