On Wed, Jul 6, 2016 at 11:07 AM, Grygorii Strashko <[email protected]> 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
