On Wed, Jul 6, 2016 at 11:07 AM, Grygorii Strashko
[off-list ref] wrote:

first of all for slow GPIO controllers (like pcf857x) it might be unsafe to call
.direction_input() from .irq_request_resources() callback because it
will be called in atomic context under raw_spin_lock_irqsave().


__setup_irq
   |- raw_spin_lock_irqsave()
        |- irq_request_resources()
        |- [ __irq_set_trigger() ]
        |- [ irq_startup() ]
        |- [ __enable_irq() ]
   |- raw_spin_unlock_irqrestore()

[and it can be unsafe for fast GPIO chips also ;( , for example if it's
required to do some kind of PM management actions before accessing HW - most of
drivers expect their GPIOchip callbacks to be called only after gpiochip.request() or
.irq_startup().]

In  my opinion this change breaks orthogonality of IRQchip vs GPIOchip interfaces
because it adds and (what is more important) hides call of GPIOchip callback
from inside IRQchip interface somewhere in  the depths of gpiolib framework.
As result, GPIO drivers lose possibility to properly handle GPIO vs IRQ interface's
differences like: locking, slow vs fast, hw specific settings, features of frameworks.

I propose to revert it, sry,

Aw typical, you are right.

OK I'll take this patch and it's fixes out of the GPIO tree :(

Yours,
Linus Walleij