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()

2021-02-12 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Arnd Bergmann [mailto:a...@kernel.org]
> Sent: Saturday, February 13, 2021 9:23 AM
> To: Grygorii Strashko 
> Cc: Song Bao Hua (Barry Song) ; Andy Shevchenko
> ; luojiaxing ; Linus
> Walleij ; Santosh Shilimkar ;
> Kevin Hilman ; open list:GPIO SUBSYSTEM
> ; linux-kernel@vger.kernel.org;
> linux...@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 12:53 PM Grygorii Strashko
>  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/c46ddb954cfe45d9849c911271d7e...@hisilicon.com/

> 
>   Arnd

Thanks
Barry



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()

2021-02-12 Thread Arnd Bergmann
On Fri, Feb 12, 2021 at 12:53 PM Grygorii Strashko
 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.

  Arnd


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()

2021-02-12 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> Sent: Saturday, February 13, 2021 3:09 AM
> To: Song Bao Hua (Barry Song) ; Andy Shevchenko
> 
> Cc: Arnd Bergmann ; luojiaxing ; Linus
> Walleij ; Santosh Shilimkar ;
> Kevin Hilman ; open list:GPIO SUBSYSTEM
> ; linux-kernel@vger.kernel.org;
> linux...@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 12/02/2021 15:12, Song Bao Hua (Barry Song) wrote:
> >
> >
> >> -Original Message-
> >> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> >> Sent: Saturday, February 13, 2021 12:53 AM
> >> To: Song Bao Hua (Barry Song) ; Andy Shevchenko
> >> 
> >> Cc: Arnd Bergmann ; luojiaxing ;
> Linus
> >> Walleij ; Santosh Shilimkar
> ;
> >> Kevin Hilman ; open list:GPIO SUBSYSTEM
> >> ; linux-kernel@vger.kernel.org;
> >> linux...@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 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:
> >>>
> >>>
>  -Original Message-
>  From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
>  Sent: Friday, February 12, 2021 11:57 PM
>  To: Song Bao Hua (Barry Song) 
>  Cc: Grygorii Strashko ; Arnd Bergmann
>  ; luojiaxing ; Linus Walleij
>  ; Santosh Shilimkar ;
> Kevin
>  Hilman ; open list:GPIO SUBSYSTEM
>  ; linux-kernel@vger.kernel.org;
>  linux...@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 10:42:19AM +, Song Bao Hua (Barry Song) 
>  wrote:
> >> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> >> Sent: Friday, February 12, 2021 11:28 PM
> >> On 12/02/2021 11:45, Arnd Bergmann wrote:
> >>> On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
> >>>  wrote:
> 
> > 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.
> >>>
> >>> 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().
> >>
> >> It will produce warning from __handle_irq_event_percpu(), as this is
> IRQ
> >> dispatcher
> >> and generic_handle_irq() will call one of handle_level_irq or
>  handle_edge_irq.
> >>
> >> The history behind this is commit 450fa54cfd66 ("gpio: omap: convert
> to
>  use
> >> generic irq handler").
> >>
> >> The resent related discussion:
> >> https://lkml.org/lkml/2020/12/5/208
> >
> > Ok, second thought. irqsave before generic_handle_irq() won't defeat
> > the purpose of preemption too much as the dispatched irq handlers by
> > gpiochip will run in their own threads but not in the thread of
> > gpiochip's handler.
> >
> > so looks like this patch can improve by:
> > * move other raw_spin_lock_irqsave to raw_spin_lock;
> > * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> > the warning in genirq.
> 
>  Isn't the idea of irqsave is to prevent dead lock from the process 
>  context
> >> when
>  we get interrupt on the *same* CPU?
> >>>
> >>> Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
> >>> spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
> >>> driver is almost always correct.
> >>>
> >>> But for gpiochip, would the below be true though it is almost alway true
> >>> for non-irq dispatcher?
> >>>
> >>> 1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so
> no
> >> more
> >>> interrupt on the same cpu -> No deadleak.
> >>>
> >>> 2. While gpiochip's handler runs in threads
> >>> * other non-threaded interrupts such as timer tick might come on same cpu,
> >>> but they are an irrelevant driver and thus they are not going to get the
> >>> lock gpiochip's handler has held. -> no deadlock.
> >>> * other devices attached to this gpiochip might get interrupts, since
> >>> gpiochip's handler is running in threads, raw_spin_lock can help avoid
> >>> messing up the critical data by two threads -> still no deadlock.
> >>
> >> The worst RT case I can imagine is 

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()

2021-02-12 Thread Grygorii Strashko




On 12/02/2021 15:12, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Saturday, February 13, 2021 12:53 AM
To: Song Bao Hua (Barry Song) ; Andy Shevchenko

Cc: Arnd Bergmann ; luojiaxing ; Linus
Walleij ; Santosh Shilimkar ;
Kevin Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@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 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
Sent: Friday, February 12, 2021 11:57 PM
To: Song Bao Hua (Barry Song) 
Cc: Grygorii Strashko ; Arnd Bergmann
; luojiaxing ; Linus Walleij
; Santosh Shilimkar ; Kevin
Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@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 10:42:19AM +, Song Bao Hua (Barry Song) wrote:

From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Friday, February 12, 2021 11:28 PM
On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 wrote:



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.

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().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ
dispatcher
and generic_handle_irq() will call one of handle_level_irq or

handle_edge_irq.


The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to

use

generic irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208


Ok, second thought. irqsave before generic_handle_irq() won't defeat
the purpose of preemption too much as the dispatched irq handlers by
gpiochip will run in their own threads but not in the thread of
gpiochip's handler.

so looks like this patch can improve by:
* move other raw_spin_lock_irqsave to raw_spin_lock;
* keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
the warning in genirq.


Isn't the idea of irqsave is to prevent dead lock from the process context

when

we get interrupt on the *same* CPU?


Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
driver is almost always correct.

But for gpiochip, would the below be true though it is almost alway true
for non-irq dispatcher?

1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no

more

interrupt on the same cpu -> No deadleak.

2. While gpiochip's handler runs in threads
* other non-threaded interrupts such as timer tick might come on same cpu,
but they are an irrelevant driver and thus they are not going to get the
lock gpiochip's handler has held. -> no deadlock.
* other devices attached to this gpiochip might get interrupts, since
gpiochip's handler is running in threads, raw_spin_lock can help avoid
messing up the critical data by two threads -> still no deadlock.


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


Actually no oops here. other drivers don't hold the same
spinlock of this driver.


huh.
driver/module A requests gpio and uses it in its hard_irq handler by calling 
GPIO API
(Like gpiod_set_value()), those will go to this driver and end up in 
omap_gpio_set().





But in general, what are the benefit of such changes at all, except better 
marking
call context annotation,
so we are spending so much time on it?


TBH, the benefit is really tiny except code cleanup. just curious how things 
could
be different while it happens in an irq dispatcher's handler.



--
Best regards,
grygorii


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()

2021-02-12 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> Sent: Saturday, February 13, 2021 12:53 AM
> To: Song Bao Hua (Barry Song) ; Andy Shevchenko
> 
> Cc: Arnd Bergmann ; luojiaxing ; Linus
> Walleij ; Santosh Shilimkar ;
> Kevin Hilman ; open list:GPIO SUBSYSTEM
> ; linux-kernel@vger.kernel.org;
> linux...@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 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:
> >
> >
> >> -Original Message-
> >> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> >> Sent: Friday, February 12, 2021 11:57 PM
> >> To: Song Bao Hua (Barry Song) 
> >> Cc: Grygorii Strashko ; Arnd Bergmann
> >> ; luojiaxing ; Linus Walleij
> >> ; Santosh Shilimkar ; Kevin
> >> Hilman ; open list:GPIO SUBSYSTEM
> >> ; linux-kernel@vger.kernel.org;
> >> linux...@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 10:42:19AM +, Song Bao Hua (Barry Song) wrote:
>  From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
>  Sent: Friday, February 12, 2021 11:28 PM
>  On 12/02/2021 11:45, Arnd Bergmann wrote:
> > On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
> >  wrote:
> >>
> >>> 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.
> >
> > 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().
> 
>  It will produce warning from __handle_irq_event_percpu(), as this is IRQ
>  dispatcher
>  and generic_handle_irq() will call one of handle_level_irq or
> >> handle_edge_irq.
> 
>  The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to
> >> use
>  generic irq handler").
> 
>  The resent related discussion:
>  https://lkml.org/lkml/2020/12/5/208
> >>>
> >>> Ok, second thought. irqsave before generic_handle_irq() won't defeat
> >>> the purpose of preemption too much as the dispatched irq handlers by
> >>> gpiochip will run in their own threads but not in the thread of
> >>> gpiochip's handler.
> >>>
> >>> so looks like this patch can improve by:
> >>> * move other raw_spin_lock_irqsave to raw_spin_lock;
> >>> * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> >>> the warning in genirq.
> >>
> >> Isn't the idea of irqsave is to prevent dead lock from the process context
> when
> >> we get interrupt on the *same* CPU?
> >
> > Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
> > spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
> > driver is almost always correct.
> >
> > But for gpiochip, would the below be true though it is almost alway true
> > for non-irq dispatcher?
> >
> > 1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no
> more
> > interrupt on the same cpu -> No deadleak.
> >
> > 2. While gpiochip's handler runs in threads
> > * other non-threaded interrupts such as timer tick might come on same cpu,
> > but they are an irrelevant driver and thus they are not going to get the
> > lock gpiochip's handler has held. -> no deadlock.
> > * other devices attached to this gpiochip might get interrupts, since
> > gpiochip's handler is running in threads, raw_spin_lock can help avoid
> > messing up the critical data by two threads -> still no deadlock.
> 
> 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

Actually no oops here. other drivers don't hold the same
spinlock of this driver.

> 
> But in general, what are the benefit of such changes at all, except better 
> marking
> call context annotation,
> so we are spending so much time on it?

TBH, the benefit is really tiny except code cleanup. just curious how things 
could
be different while it happens in an irq dispatcher's handler.

> 
> 
> --
> Best regards,
> Grygorii

Thanks

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()

2021-02-12 Thread Grygorii Strashko




On 12/02/2021 13:29, Song Bao Hua (Barry Song) wrote:




-Original Message-
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
Sent: Friday, February 12, 2021 11:57 PM
To: Song Bao Hua (Barry Song) 
Cc: Grygorii Strashko ; Arnd Bergmann
; luojiaxing ; Linus Walleij
; Santosh Shilimkar ; Kevin
Hilman ; open list:GPIO SUBSYSTEM
; linux-kernel@vger.kernel.org;
linux...@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 10:42:19AM +, Song Bao Hua (Barry Song) wrote:

From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
Sent: Friday, February 12, 2021 11:28 PM
On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 wrote:



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.

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().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ
dispatcher
and generic_handle_irq() will call one of handle_level_irq or

handle_edge_irq.


The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to

use

generic irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208


Ok, second thought. irqsave before generic_handle_irq() won't defeat
the purpose of preemption too much as the dispatched irq handlers by
gpiochip will run in their own threads but not in the thread of
gpiochip's handler.

so looks like this patch can improve by:
* move other raw_spin_lock_irqsave to raw_spin_lock;
* keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
the warning in genirq.


Isn't the idea of irqsave is to prevent dead lock from the process context when
we get interrupt on the *same* CPU?


Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
driver is almost always correct.

But for gpiochip, would the below be true though it is almost alway true
for non-irq dispatcher?

1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no more
interrupt on the same cpu -> No deadleak.

2. While gpiochip's handler runs in threads
* other non-threaded interrupts such as timer tick might come on same cpu,
but they are an irrelevant driver and thus they are not going to get the
lock gpiochip's handler has held. -> no deadlock.
* other devices attached to this gpiochip might get interrupts, since
gpiochip's handler is running in threads, raw_spin_lock can help avoid
messing up the critical data by two threads -> still no deadlock.


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

But in general, what are the benefit of such changes at all, except better 
marking call context annotation,
so we are spending so much time on it?


--
Best regards,
grygorii


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()

2021-02-12 Thread Andy Shevchenko
On Fri, Feb 12, 2021 at 11:59:28AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 12, 2021 at 11:42 AM Song Bao Hua (Barry Song)
>  wrote:
> >
> > Ok, second thought. irqsave before generic_handle_irq() won't defeat
> > the purpose of preemption too much as the dispatched irq handlers by
> > gpiochip will run in their own threads but not in the thread of
> > gpiochip's handler.
> >
> > so looks like this patch can improve by:
> > * move other raw_spin_lock_irqsave to raw_spin_lock;
> > * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> > the warning in genirq.
> 
> It seems that the other drivers just call handle_nested_irq() instead
> of generic_handle_irq().

And IIRC all of them request threaded IRQ explicitly.

-- 
With Best Regards,
Andy Shevchenko




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()

2021-02-12 Thread Song Bao Hua (Barry Song)



> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Friday, February 12, 2021 11:57 PM
> To: Song Bao Hua (Barry Song) 
> Cc: Grygorii Strashko ; Arnd Bergmann
> ; luojiaxing ; Linus Walleij
> ; Santosh Shilimkar ; Kevin
> Hilman ; open list:GPIO SUBSYSTEM
> ; linux-kernel@vger.kernel.org;
> linux...@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 10:42:19AM +, Song Bao Hua (Barry Song) wrote:
> > > From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> > > Sent: Friday, February 12, 2021 11:28 PM
> > > On 12/02/2021 11:45, Arnd Bergmann wrote:
> > > > On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
> > > >  wrote:
> 
> > > >>> 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.
> > > >
> > > > 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().
> > >
> > > It will produce warning from __handle_irq_event_percpu(), as this is IRQ
> > > dispatcher
> > > and generic_handle_irq() will call one of handle_level_irq or
> handle_edge_irq.
> > >
> > > The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to
> use
> > > generic irq handler").
> > >
> > > The resent related discussion:
> > > https://lkml.org/lkml/2020/12/5/208
> >
> > Ok, second thought. irqsave before generic_handle_irq() won't defeat
> > the purpose of preemption too much as the dispatched irq handlers by
> > gpiochip will run in their own threads but not in the thread of
> > gpiochip's handler.
> >
> > so looks like this patch can improve by:
> > * move other raw_spin_lock_irqsave to raw_spin_lock;
> > * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> > the warning in genirq.
> 
> Isn't the idea of irqsave is to prevent dead lock from the process context 
> when
> we get interrupt on the *same* CPU?

Anyway, gpiochip is more tricky as it is also a irq dispatcher. Moving
spin_lock_irq to spin_lock in the irq handler of non-irq dispatcher
driver is almost always correct.

But for gpiochip, would the below be true though it is almost alway true
for non-irq dispatcher?

1. While gpiochip's handler runs in hardIRQ, interrupts are disabled, so no more
interrupt on the same cpu -> No deadleak.

2. While gpiochip's handler runs in threads
* other non-threaded interrupts such as timer tick might come on same cpu,
but they are an irrelevant driver and thus they are not going to get the
lock gpiochip's handler has held. -> no deadlock.
* other devices attached to this gpiochip might get interrupts, since 
gpiochip's handler is running in threads, raw_spin_lock can help avoid
messing up the critical data by two threads -> still no deadlock.

> 
> --
> With Best Regards,
> Andy Shevchenko
> 

Thanks
Barry



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()

2021-02-12 Thread Arnd Bergmann
On Fri, Feb 12, 2021 at 11:42 AM Song Bao Hua (Barry Song)
 wrote:
>
> Ok, second thought. irqsave before generic_handle_irq() won't defeat
> the purpose of preemption too much as the dispatched irq handlers by
> gpiochip will run in their own threads but not in the thread of
> gpiochip's handler.
>
> so looks like this patch can improve by:
> * move other raw_spin_lock_irqsave to raw_spin_lock;
> * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> the warning in genirq.

It seems that the other drivers just call handle_nested_irq() instead
of generic_handle_irq().

   Arnd


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()

2021-02-12 Thread Andy Shevchenko
On Fri, Feb 12, 2021 at 10:42:19AM +, Song Bao Hua (Barry Song) wrote:
> > From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> > Sent: Friday, February 12, 2021 11:28 PM
> > On 12/02/2021 11:45, Arnd Bergmann wrote:
> > > On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
> > >  wrote:

> > >>> 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.
> > >
> > > 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().
> > 
> > It will produce warning from __handle_irq_event_percpu(), as this is IRQ
> > dispatcher
> > and generic_handle_irq() will call one of handle_level_irq or 
> > handle_edge_irq.
> > 
> > The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to use
> > generic irq handler").
> > 
> > The resent related discussion:
> > https://lkml.org/lkml/2020/12/5/208
> 
> Ok, second thought. irqsave before generic_handle_irq() won't defeat
> the purpose of preemption too much as the dispatched irq handlers by
> gpiochip will run in their own threads but not in the thread of
> gpiochip's handler.
> 
> so looks like this patch can improve by:
> * move other raw_spin_lock_irqsave to raw_spin_lock;
> * keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
> the warning in genirq.

Isn't the idea of irqsave is to prevent dead lock from the process context when
we get interrupt on the *same* CPU?

-- 
With Best Regards,
Andy Shevchenko




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()

2021-02-12 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> Sent: Friday, February 12, 2021 11:28 PM
> To: Arnd Bergmann ; Song Bao Hua (Barry Song)
> 
> Cc: luojiaxing ; Linus Walleij
> ; Andy Shevchenko ; Andy
> Shevchenko ; Santosh Shilimkar
> ; Kevin Hilman ; open list:GPIO
> SUBSYSTEM ; linux-kernel@vger.kernel.org;
> linux...@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()
> 
> Hi Arnd,
> 
> On 12/02/2021 11:45, Arnd Bergmann wrote:
> > On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
> >  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.
> >
> > 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().
> 
> It will produce warning from __handle_irq_event_percpu(), as this is IRQ
> dispatcher
> and generic_handle_irq() will call one of handle_level_irq or handle_edge_irq.
> 
> The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to use
> generic irq handler").
> 
> The resent related discussion:
> https://lkml.org/lkml/2020/12/5/208

Ok, second thought. irqsave before generic_handle_irq() won't defeat
the purpose of preemption too much as the dispatched irq handlers by
gpiochip will run in their own threads but not in the thread of
gpiochip's handler.

so looks like this patch can improve by:
* move other raw_spin_lock_irqsave to raw_spin_lock;
* keep the raw_spin_lock_irqsave before generic_handle_irq() to mute
the warning in genirq.

> 
> 
> 
> --
> Best regards,
> Grygorii

Thanks
Barry



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()

2021-02-12 Thread Grygorii Strashko

Hi Arnd,

On 12/02/2021 11:45, Arnd Bergmann wrote:

On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 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.

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().


It will produce warning from __handle_irq_event_percpu(), as this is IRQ 
dispatcher
and generic_handle_irq() will call one of handle_level_irq or handle_edge_irq.

The history behind this is commit 450fa54cfd66 ("gpio: omap: convert to use generic 
irq handler").

The resent related discussion:
https://lkml.org/lkml/2020/12/5/208



--
Best regards,
grygorii


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()

2021-02-12 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Arnd Bergmann [mailto:a...@kernel.org]
> Sent: Friday, February 12, 2021 10:45 PM
> To: Song Bao Hua (Barry Song) 
> Cc: Grygorii Strashko ; luojiaxing
> ; Linus Walleij ; Andy
> Shevchenko ; Andy Shevchenko
> ; Santosh Shilimkar ;
> Kevin Hilman ; open list:GPIO SUBSYSTEM
> , linux-kernel@vger.kernel.org
> ; linux...@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)
>  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


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()

2021-02-12 Thread Arnd Bergmann
On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song)
 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.

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().

   Arnd


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()

2021-02-11 Thread Song Bao Hua (Barry Song)


> -Original Message-
> From: Grygorii Strashko [mailto:grygorii.stras...@ti.com]
> Sent: Friday, February 12, 2021 9:17 AM
> To: Arnd Bergmann 
> Cc: luojiaxing ; Linus Walleij
> ; Andy Shevchenko ; Andy
> Shevchenko ; Santosh Shilimkar
> ; Kevin Hilman ; open list:GPIO
> SUBSYSTEM , linux-kernel@vger.kernel.org
> ; linux...@openeuler.org
> Subject: [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 11/02/2021 21:39, Arnd Bergmann wrote:
> > On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
> >  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.
> 
> 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.

On the other hand, the author changed a couple of spin_lock_irqsave
to spin_lock, if only this one is incorrect, it seems it is worth a
new version to fix this.

> 
> --
> Best regards,
> grygorii

Thanks
Barry



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

2021-02-11 Thread Grygorii Strashko




On 11/02/2021 21:39, Arnd Bergmann wrote:

On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
 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.


Note. there is also generic_handle_irq() call inside.

--
Best regards,
grygorii


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

2021-02-11 Thread Arnd Bergmann
On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko
 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


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

2021-02-11 Thread Grygorii Strashko




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.

Signed-off-by: Luo Jiaxing 
---
  drivers/gpio/gpio-omap.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 41952bb..dc8bbf4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -560,8 +560,6 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
u32 enabled, isr, edge;
unsigned int bit;
struct gpio_bank *bank = gpiobank;
-   unsigned long wa_lock_flags;
-   unsigned long lock_flags;
  
  	isr_reg = bank->base + bank->regs->irqstatus;

if (WARN_ON(!isr_reg))
@@ -572,7 +570,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
return IRQ_NONE;
  
  	while (1) {

-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
  
  		enabled = omap_get_gpio_irqbank_mask(bank);

isr = readl_relaxed(isr_reg) & enabled;
@@ -586,7 +584,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (edge)
omap_clear_gpio_irqbank(bank, edge);
  
-		raw_spin_unlock_irqrestore(>lock, lock_flags);

+   raw_spin_unlock(>lock);
  
  		if (!isr)

break;
@@ -595,7 +593,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
bit = __ffs(isr);
isr &= ~(BIT(bit));
  
-			raw_spin_lock_irqsave(>lock, lock_flags);

+   raw_spin_lock(>lock);
/*
 * Some chips can't respond to both rising and falling
 * at the same time.  If this irq was requested with
@@ -606,15 +604,14 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (bank->toggle_mask & (BIT(bit)))
omap_toggle_gpio_edge_triggering(bank, bit);
  
-			raw_spin_unlock_irqrestore(>lock, lock_flags);

+   raw_spin_unlock(>lock);
  
-			raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);

+   raw_spin_lock(>wa_lock);
  
  			generic_handle_irq(irq_find_mapping(bank->chip.irq.domain,

bit));
  
-			raw_spin_unlock_irqrestore(>wa_lock,

-  wa_lock_flags);
+   raw_spin_unlock(>wa_lock);
}
}
  exit:



NACK.
Who said that this is always hard IRQ handler?
What about RT-kernel or boot with "threadirqs"?

--
Best regards,
grygorii


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

2021-02-08 Thread Luo Jiaxing
There is no need to use API with _irqsave in omap_gpio_irq_handler(),
because it already be in a irq-disabled context.

Signed-off-by: Luo Jiaxing 
---
 drivers/gpio/gpio-omap.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 41952bb..dc8bbf4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -560,8 +560,6 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
u32 enabled, isr, edge;
unsigned int bit;
struct gpio_bank *bank = gpiobank;
-   unsigned long wa_lock_flags;
-   unsigned long lock_flags;
 
isr_reg = bank->base + bank->regs->irqstatus;
if (WARN_ON(!isr_reg))
@@ -572,7 +570,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
return IRQ_NONE;
 
while (1) {
-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
 
enabled = omap_get_gpio_irqbank_mask(bank);
isr = readl_relaxed(isr_reg) & enabled;
@@ -586,7 +584,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (edge)
omap_clear_gpio_irqbank(bank, edge);
 
-   raw_spin_unlock_irqrestore(>lock, lock_flags);
+   raw_spin_unlock(>lock);
 
if (!isr)
break;
@@ -595,7 +593,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
bit = __ffs(isr);
isr &= ~(BIT(bit));
 
-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
/*
 * Some chips can't respond to both rising and falling
 * at the same time.  If this irq was requested with
@@ -606,15 +604,14 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (bank->toggle_mask & (BIT(bit)))
omap_toggle_gpio_edge_triggering(bank, bit);
 
-   raw_spin_unlock_irqrestore(>lock, lock_flags);
+   raw_spin_unlock(>lock);
 
-   raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);
+   raw_spin_lock(>wa_lock);
 

generic_handle_irq(irq_find_mapping(bank->chip.irq.domain,
bit));
 
-   raw_spin_unlock_irqrestore(>wa_lock,
-  wa_lock_flags);
+   raw_spin_unlock(>wa_lock);
}
}
 exit:
-- 
2.7.4



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

2021-02-08 Thread Luo Jiaxing
There is no need to use API with _irqsave in omap_gpio_irq_handler(),
because it already be in a irq-disabled context.

Signed-off-by: Luo Jiaxing 
---
 drivers/gpio/gpio-omap.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 41952bb..dc8bbf4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -560,8 +560,6 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
u32 enabled, isr, edge;
unsigned int bit;
struct gpio_bank *bank = gpiobank;
-   unsigned long wa_lock_flags;
-   unsigned long lock_flags;
 
isr_reg = bank->base + bank->regs->irqstatus;
if (WARN_ON(!isr_reg))
@@ -572,7 +570,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
return IRQ_NONE;
 
while (1) {
-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
 
enabled = omap_get_gpio_irqbank_mask(bank);
isr = readl_relaxed(isr_reg) & enabled;
@@ -586,7 +584,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (edge)
omap_clear_gpio_irqbank(bank, edge);
 
-   raw_spin_unlock_irqrestore(>lock, lock_flags);
+   raw_spin_unlock(>lock);
 
if (!isr)
break;
@@ -595,7 +593,7 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
bit = __ffs(isr);
isr &= ~(BIT(bit));
 
-   raw_spin_lock_irqsave(>lock, lock_flags);
+   raw_spin_lock(>lock);
/*
 * Some chips can't respond to both rising and falling
 * at the same time.  If this irq was requested with
@@ -606,15 +604,14 @@ static irqreturn_t omap_gpio_irq_handler(int irq, void 
*gpiobank)
if (bank->toggle_mask & (BIT(bit)))
omap_toggle_gpio_edge_triggering(bank, bit);
 
-   raw_spin_unlock_irqrestore(>lock, lock_flags);
+   raw_spin_unlock(>lock);
 
-   raw_spin_lock_irqsave(>wa_lock, wa_lock_flags);
+   raw_spin_lock(>wa_lock);
 

generic_handle_irq(irq_find_mapping(bank->chip.irq.domain,
bit));
 
-   raw_spin_unlock_irqrestore(>wa_lock,
-  wa_lock_flags);
+   raw_spin_unlock(>wa_lock);
}
}
 exit:
-- 
2.7.4