-----Original Message----- From: Arnd Bergmann [mailto:arnd@kernel.org] Sent: Friday, February 12, 2021 10:45 PM To: Song Bao Hua (Barry Song) song.bao.hua@hisilicon.com Cc: Grygorii Strashko grygorii.strashko@ti.com; luojiaxing luojiaxing@huawei.com; Linus Walleij linus.walleij@linaro.org; Andy Shevchenko andy.shevchenko@gmail.com; Andy Shevchenko andriy.shevchenko@linux.intel.com; Santosh Shilimkar ssantosh@kernel.org; Kevin Hilman khilman@kernel.org; open list:GPIO SUBSYSTEM linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org; linuxarm@openeuler.org 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 6:05 AM Song Bao Hua (Barry Song) song.bao.hua@hisilicon.com wrote:
-----Original Message-----
Note. there is also generic_handle_irq() call inside.
So generic_handle_irq() is not safe to run in thread thus requires an interrupt-disabled environment to run? If so, I'd rather this irqsave moved into generic_handle_irq() rather than asking everyone calling it to do irqsave.
In a preempt-rt kernel, interrupts are run in task context, so they clearly should not be called with interrupts disabled, that would defeat the purpose of making them preemptible.
Yes. Sounds sensible. Irqsave in generic_handle_irq() will defeat the purpose of RT.
generic_handle_irq() does need to run with in_irq()==true though, but this should be set by the caller of the gpiochip's handler, and it is not set by raw_spin_lock_irqsave().
So sounds like this issue of in_irq()=true is still irrelevant with this patch.
I guess this should have been set by the caller of the gpiochip's handler somewhere, otherwise, gpiochip's irq handler won't be able to be threaded. Has it been set somewhere?
Arnd
Thanks Barry