[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0m4ocfLyJZ5wMxyKESYUJ5um5sb5MyAzC8ckCb6qAH5g@mail.gmail.com>
Date: Thu, 11 Feb 2021 20:39:09 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Grygorii Strashko <grygorii.strashko@...com>
Cc: Luo Jiaxing <luojiaxing@...wei.com>,
Linus Walleij <linus.walleij@...aro.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Santosh Shilimkar <ssantosh@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linuxarm@...neuler.org
Subject: Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave
with raw_spin_lock in omap_gpio_irq_handler()
On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
<grygorii.strashko@...com> wrote:
> On 08/02/2021 10:56, Luo Jiaxing wrote:
> > There is no need to use API with _irqsave in omap_gpio_irq_handler(),
> > because it already be in a irq-disabled context.
>
> NACK.
> Who said that this is always hard IRQ handler?
> What about RT-kernel or boot with "threadirqs"?
In those cases, the interrupt handler is just a normal thread, so the
preempt_disable() that is implied by raw_spin_lock() is sufficient.
Disabling interrupts inside of an interrupt handler is always incorrect,
the patch looks like a useful cleanup to me, if only for readability.
Arnd
Powered by blists - more mailing lists