RE: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()

[Song Bao Hua (Barry Song)]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@xxxxxxxxxx]
> Sent: Saturday, February 13, 2021 9:23 AM
> To: Grygorii Strashko <grygorii.strashko@xxxxxx>
> Cc: Song Bao Hua (Barry Song) <song.bao.hua@xxxxxxxxxxxxx>; Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx>; luojiaxing <luojiaxing@xxxxxxxxxx>; Linus
> Walleij <linus.walleij@xxxxxxxxxx>; Santosh Shilimkar <ssantosh@xxxxxxxxxx>;
> Kevin Hilman <khilman@xxxxxxxxxx>; open list:GPIO SUBSYSTEM
> <linux-gpio@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> linuxarm@xxxxxxxxxxxxx
> Subject: Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace
> raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()
> 
> On Fri, Feb 12, 2021 at 12:53 PM Grygorii Strashko
> <grygorii.strashko@xxxxxx> wrote:
> >
> > The worst RT case I can imagine is when gpio API is still called from hard
> IRQ context by some
> > other device driver - some toggling for example.
> > Note. RT or "threadirqs" does not mean gpiochip become sleepable.
> >
> > In this case:
> >   threaded handler
> >     raw_spin_lock
> >         IRQ from other device
> >            hard_irq handler
> >              gpiod_x()
> >                 raw_spin_lock_irqsave() -- oops
> >
> 
> Good point, I had missed the fact that drivers can call gpio functions from
> hardirq context when I replied earlier, gpio is clearly special here.


Yes. Gpio provides APIs, thus, other drivers can go directly into the
territory of gpio driver.

Another one which is even more special might be m68k, which I cc-ed you
yesterday:
https://lore.kernel.org/lkml/c46ddb954cfe45d9849c911271d7ec23@xxxxxxxxxxxxx/

> 
>           Arnd

Thanks
Barry