| Message ID | 1612774577-55943-1-git-send-email-luojiaxing@huawei.com |
|---|---|
| Headers | show |
| Series | gpio: few clean up patches to replace spin_lock_irqsave with spin_lock | expand |
Sorry, my operation error causes a patch missing from this patch set. I re-send the patch set. Please check the new one. On 2021/2/8 16:56, Luo Jiaxing wrote: > There is no need to use API with _irqsave in hard IRQ handler, So replace > those with spin_lock. > > Luo Jiaxing (2): > gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in > omap_gpio_irq_handler() > gpio: grgpio: Replace spin_lock_irqsave with spin_lock in > grgpio_irq_handler() > > drivers/gpio/gpio-grgpio.c | 5 ++--- > drivers/gpio/gpio-omap.c | 15 ++++++--------- > 2 files changed, 8 insertions(+), 12 deletions(-) >
On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: > > Sorry, my operation error causes a patch missing from this patch set. I > re-send the patch set. Please check the new one. What is the new one?! You have to give proper versioning and change log for your series. > On 2021/2/8 16:56, Luo Jiaxing wrote: > > There is no need to use API with _irqsave in hard IRQ handler, So replace > > those with spin_lock. How do you know that another CPU in the system can't serve the following interrupt from the hardware at the same time?
On 2021/2/8 21:28, Andy Shevchenko wrote: > On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: >> Sorry, my operation error causes a patch missing from this patch set. I >> re-send the patch set. Please check the new one. > What is the new one?! You have to give proper versioning and change > log for your series. sure, I will send a new one later, but let me answer your question first. > >> On 2021/2/8 16:56, Luo Jiaxing wrote: >>> There is no need to use API with _irqsave in hard IRQ handler, So replace >>> those with spin_lock. > How do you know that another CPU in the system can't serve the > following interrupt from the hardware at the same time? Yes, I have some question before. There are some similar discussion here, please take a look, Song baohua explained it more professionally. https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.com/ Here are some excerpts from the discussion: I think the code disabling irq in hardIRQ is simply wrong. Since this commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc genirq: Run irq handlers with interrupts disabled interrupt handlers are definitely running in a irq-disabled context unless irq handlers enable them explicitly in the handler to permit other interrupts. Thanks Jiaxing >
On Tue, Feb 9, 2021 at 11:24 AM luojiaxing <luojiaxing@huawei.com> wrote: > On 2021/2/8 21:28, Andy Shevchenko wrote: > > On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: > >> Sorry, my operation error causes a patch missing from this patch set. I > >> re-send the patch set. Please check the new one. > > What is the new one?! You have to give proper versioning and change > > log for your series. > > sure, I will send a new one later, but let me answer your question first. > > >> On 2021/2/8 16:56, Luo Jiaxing wrote: > >>> There is no need to use API with _irqsave in hard IRQ handler, So replace > >>> those with spin_lock. > > How do you know that another CPU in the system can't serve the The keyword here is: *another*. > > following interrupt from the hardware at the same time? > > Yes, I have some question before. > > There are some similar discussion here, please take a look, Song baohua > explained it more professionally. > > https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.com/ > > Here are some excerpts from the discussion: > > I think the code disabling irq in hardIRQ is simply wrong. Why? > Since this commit > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > genirq: Run irq handlers with interrupts disabled > > interrupt handlers are definitely running in a irq-disabled context > unless irq handlers enable them explicitly in the handler to permit > other interrupts. This doesn't explain any changes in the behaviour on SMP. IRQ line can be disabled on a few stages: a) on the source (IP that generates an event) b) on IRQ router / controller c) on CPU side The commit above is discussing (rightfully!) the problem when all interrupts are being served by a *single* core. Nobody prevents them from being served by *different* cores simultaneously. Also, see [1]. [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html
On 2021/2/9 17:42, Andy Shevchenko wrote: > On Tue, Feb 9, 2021 at 11:24 AM luojiaxing <luojiaxing@huawei.com> wrote: >> On 2021/2/8 21:28, Andy Shevchenko wrote: >>> On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: >>>> Sorry, my operation error causes a patch missing from this patch set. I >>>> re-send the patch set. Please check the new one. >>> What is the new one?! You have to give proper versioning and change >>> log for your series. >> sure, I will send a new one later, but let me answer your question first. >> >>>> On 2021/2/8 16:56, Luo Jiaxing wrote: >>>>> There is no need to use API with _irqsave in hard IRQ handler, So replace >>>>> those with spin_lock. >>> How do you know that another CPU in the system can't serve the > The keyword here is: *another*. ooh, sorry, now I got your point. As to me, I don't think another CPU can serve the IRQ when one CPU runing hard IRQ handler, except it's a per CPU interrupts. The following is a simple call logic when IRQ come. elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> handle_irq_event Assume that two CPUs receive the same IRQ and enter the preceding process. Both of them will go to desc->handle_irq(). In handle_irq(), raw_spin_lock(&desc->lock) always be called first. Therefore, even if two CPUs are running handle_irq(), only one can get the spin lock. Assume that CPU A obtains the spin lock. Then CPU A will sets the status of irq_data to IRQD_IRQ_INPROGRESS in handle_irq_event() and releases the spin lock. Even though CPU B gets the spin lock later and continue to run handle_irq(), but the check of irq_may_run(desc) causes it to exit. so, I think we don't own the situation that two CPU server the hard IRQ handler at the same time. > >>> following interrupt from the hardware at the same time? >> Yes, I have some question before. >> >> There are some similar discussion here, please take a look, Song baohua >> explained it more professionally. >> >> https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.com/ >> >> Here are some excerpts from the discussion: >> >> I think the code disabling irq in hardIRQ is simply wrong. > Why? I mention the following call before. elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> handle_irq_event __handle_domain_irq() will call irq_enter(), it ensures that the IRQ processing of the current CPU can not be preempted. So I think this is the reason why Song baohua said it's not need to disable IRQ in hardIRQ handler. > >> Since this commit >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc >> genirq: Run irq handlers with interrupts disabled >> >> interrupt handlers are definitely running in a irq-disabled context >> unless irq handlers enable them explicitly in the handler to permit >> other interrupts. > This doesn't explain any changes in the behaviour on SMP. > IRQ line can be disabled on a few stages: > a) on the source (IP that generates an event) > b) on IRQ router / controller > c) on CPU side yes, you are right. > > The commit above is discussing (rightfully!) the problem when all > interrupts are being served by a *single* core. Nobody prevents them > from being served by *different* cores simultaneously. Also, see [1]. > > [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html I check [1], quite useful description about locking, thanks. But you can see Table of locking Requirements Between IRQ handler A and IRQ handle A, it's no need for a SLIS. Thanks Jiaxing >
On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote: > On 2021/2/9 17:42, Andy Shevchenko wrote: > > On Tue, Feb 9, 2021 at 11:24 AM luojiaxing <luojiaxing@huawei.com> wrote: > >> On 2021/2/8 21:28, Andy Shevchenko wrote: > >>> On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: > >>>> On 2021/2/8 16:56, Luo Jiaxing wrote: > >>>>> There is no need to use API with _irqsave in hard IRQ handler, So replace > >>>>> those with spin_lock. > >>> How do you know that another CPU in the system can't serve the > > The keyword here is: *another*. > > ooh, sorry, now I got your point. > > As to me, I don't think another CPU can serve the IRQ when one CPU > runing hard IRQ handler, Why is it so? Each CPU can serve IRQs separately. > except it's a per CPU interrupts. I didn't get how it is related. > The following is a simple call logic when IRQ come. > > elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> > handle_irq_event What is `elx_irq()`? I haven't found any mention of this in the kernel source tree. But okay, it shouldn't prevent our discussion. > Assume that two CPUs receive the same IRQ and enter the preceding > process. Both of them will go to desc->handle_irq(). Ah, I'm talking about the same IRQ by number (like Linux IRQ number, means from the same source), but with different sequence number (means two consequent events). > In handle_irq(), raw_spin_lock(&desc->lock) always be called first. > Therefore, even if two CPUs are running handle_irq(), > > only one can get the spin lock. Assume that CPU A obtains the spin lock. > Then CPU A will sets the status of irq_data to > > IRQD_IRQ_INPROGRESS in handle_irq_event() and releases the spin lock. > Even though CPU B gets the spin lock later and > > continue to run handle_irq(), but the check of irq_may_run(desc) causes > it to exit. > > > so, I think we don't own the situation that two CPU server the hard IRQ > handler at the same time. Okay. Assuming your analysis is correct, have you considered the case when all IRQ handlers are threaded? (There is a kernel command line option to force this) > >>> following interrupt from the hardware at the same time? > >> Yes, I have some question before. > >> > >> There are some similar discussion here, please take a look, Song baohua > >> explained it more professionally. > >> > >> https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.com/ > >> > >> Here are some excerpts from the discussion: > >> > >> I think the code disabling irq in hardIRQ is simply wrong. > > Why? > > > I mention the following call before. > > elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> > handle_irq_event > > > __handle_domain_irq() will call irq_enter(), it ensures that the IRQ > processing of the current CPU can not be preempted. > > So I think this is the reason why Song baohua said it's not need to > disable IRQ in hardIRQ handler. > > >> Since this commit > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > >> genirq: Run irq handlers with interrupts disabled > >> > >> interrupt handlers are definitely running in a irq-disabled context > >> unless irq handlers enable them explicitly in the handler to permit > >> other interrupts. > > This doesn't explain any changes in the behaviour on SMP. > > IRQ line can be disabled on a few stages: > > a) on the source (IP that generates an event) > > b) on IRQ router / controller > > c) on CPU side > > yes, you are right. > > > The commit above is discussing (rightfully!) the problem when all > > interrupts are being served by a *single* core. Nobody prevents them > > from being served by *different* cores simultaneously. Also, see [1]. > > > > [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html > > I check [1], quite useful description about locking, thanks. But you can > see Table of locking Requirements > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS. Right, but it's not the case in the patches you provided. -- With Best Regards, Andy Shevchenko
> -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > Sent: Wednesday, February 10, 2021 11:51 PM > To: luojiaxing <luojiaxing@huawei.com> > Cc: Linus Walleij <linus.walleij@linaro.org>; Andy Shevchenko > <andriy.shevchenko@linux.intel.com>; Grygorii Strashko > <grygorii.strashko@ti.com>; Santosh Shilimkar <ssantosh@kernel.org>; Kevin > Hilman <khilman@kernel.org>; open list:GPIO SUBSYSTEM > <linux-gpio@vger.kernel.org>; Linux Kernel Mailing List > <linux-kernel@vger.kernel.org>; linuxarm@openeuler.org > Subject: [Linuxarm] Re: [PATCH for next v1 0/2] gpio: few clean up patches to > replace spin_lock_irqsave with spin_lock > > On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote: > > On 2021/2/9 17:42, Andy Shevchenko wrote: > > > On Tue, Feb 9, 2021 at 11:24 AM luojiaxing <luojiaxing@huawei.com> wrote: > > >> On 2021/2/8 21:28, Andy Shevchenko wrote: > > >>> On Mon, Feb 8, 2021 at 11:11 AM luojiaxing <luojiaxing@huawei.com> wrote: > > >>>> On 2021/2/8 16:56, Luo Jiaxing wrote: > > >>>>> There is no need to use API with _irqsave in hard IRQ handler, So replace > > >>>>> those with spin_lock. > > >>> How do you know that another CPU in the system can't serve the > > > The keyword here is: *another*. > > > > ooh, sorry, now I got your point. > > > > As to me, I don't think another CPU can serve the IRQ when one CPU > > runing hard IRQ handler, > > Why is it so? > Each CPU can serve IRQs separately. > > > except it's a per CPU interrupts. > > I didn't get how it is related. > > > The following is a simple call logic when IRQ come. > > > > elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> > > handle_irq_event > > What is `elx_irq()`? I haven't found any mention of this in the kernel > source tree. > But okay, it shouldn't prevent our discussion. > > > Assume that two CPUs receive the same IRQ and enter the preceding > > process. Both of them will go to desc->handle_irq(). > > Ah, I'm talking about the same IRQ by number (like Linux IRQ number, > means from the same source), but with different sequence number (means > two consequent events). > > > In handle_irq(), raw_spin_lock(&desc->lock) always be called first. > > Therefore, even if two CPUs are running handle_irq(), > > > > only one can get the spin lock. Assume that CPU A obtains the spin lock. > > Then CPU A will sets the status of irq_data to > > > > IRQD_IRQ_INPROGRESS in handle_irq_event() and releases the spin lock. > > Even though CPU B gets the spin lock later and > > > > continue to run handle_irq(), but the check of irq_may_run(desc) causes > > it to exit. > > > > > > so, I think we don't own the situation that two CPU server the hard IRQ > > handler at the same time. > > Okay. Assuming your analysis is correct, have you considered the case > when all IRQ handlers are threaded? (There is a kernel command line > option to force this) > > > >>> following interrupt from the hardware at the same time? > > >> Yes, I have some question before. > > >> > > >> There are some similar discussion here, please take a look, Song baohua > > >> explained it more professionally. > > >> > > >> > https://lore.kernel.org/lkml/e949a474a9284ac6951813bfc8b34945@hisilicon.co > m/ > > >> > > >> Here are some excerpts from the discussion: > > >> > > >> I think the code disabling irq in hardIRQ is simply wrong. > > > Why? > > > > > > I mention the following call before. > > > > elx_irq -> handle_arch_irq -> __handle_domain_irq -> desc->handle_irq -> > > handle_irq_event > > > > > > __handle_domain_irq() will call irq_enter(), it ensures that the IRQ > > processing of the current CPU can not be preempted. > > > > So I think this is the reason why Song baohua said it's not need to > > disable IRQ in hardIRQ handler. > > > > >> Since this commit > > >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=e58aa3d2d0cc > > >> genirq: Run irq handlers with interrupts disabled > > >> > > >> interrupt handlers are definitely running in a irq-disabled context > > >> unless irq handlers enable them explicitly in the handler to permit > > >> other interrupts. > > > This doesn't explain any changes in the behaviour on SMP. > > > IRQ line can be disabled on a few stages: > > > a) on the source (IP that generates an event) > > > b) on IRQ router / controller > > > c) on CPU side > > > > yes, you are right. > > > > > The commit above is discussing (rightfully!) the problem when all > > > interrupts are being served by a *single* core. Nobody prevents them > > > from being served by *different* cores simultaneously. Also, see [1]. > > > > > > [1]: https://www.kernel.org/doc/htmldocs/kernel-locking/cheatsheet.html > > > > I check [1], quite useful description about locking, thanks. But you can > > see Table of locking Requirements > > > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS. > > Right, but it's not the case in the patches you provided. The code still holds spin_lock. So if two cpus call same IRQ handler, spin_lock makes them spin; and if interrupts are threaded, spin_lock makes two threads run the same handler one by one. > > -- > With Best Regards, > Andy Shevchenko Thanks Barry
On Wed, Feb 10, 2021 at 11:50:45AM +0000, Song Bao Hua (Barry Song) wrote: > > -----Original Message----- > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > Sent: Wednesday, February 10, 2021 11:51 PM > > On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote: > > > On 2021/2/9 17:42, Andy Shevchenko wrote: ... > > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS. > > > > Right, but it's not the case in the patches you provided. > > The code still holds spin_lock. So if two cpus call same IRQ handler, > spin_lock makes them spin; and if interrupts are threaded, spin_lock > makes two threads run the same handler one by one. If you run on an SMP system and it happens that spin_lock_irqsave() just immediately after spin_unlock(), you will get into the troubles. Am I mistaken? I think this entire activity is a carefully crafted mine field for the future syzcaller and fuzzers alike. I don't believe there are no side effects in a long term on all possible systems and configurations (including forced threaded IRQ handlers). I would love to see a better explanation in the commit message of such patches which makes it clear that there are *no* side effects. For time being, NAK to the all patches of this kind.
> -----Original Message----- > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > Sent: Thursday, February 11, 2021 3:57 AM > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com> > Cc: luojiaxing <luojiaxing@huawei.com>; Linus Walleij > <linus.walleij@linaro.org>; Grygorii Strashko <grygorii.strashko@ti.com>; > Santosh Shilimkar <ssantosh@kernel.org>; Kevin Hilman <khilman@kernel.org>; > open list:GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>; Linux Kernel Mailing > List <linux-kernel@vger.kernel.org>; linuxarm@openeuler.org > Subject: Re: [Linuxarm] Re: [PATCH for next v1 0/2] gpio: few clean up patches > to replace spin_lock_irqsave with spin_lock > > On Wed, Feb 10, 2021 at 11:50:45AM +0000, Song Bao Hua (Barry Song) wrote: > > > -----Original Message----- > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > > Sent: Wednesday, February 10, 2021 11:51 PM > > > On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote: > > > > On 2021/2/9 17:42, Andy Shevchenko wrote: > > ... > > > > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS. > > > > > > Right, but it's not the case in the patches you provided. > > > > The code still holds spin_lock. So if two cpus call same IRQ handler, > > spin_lock makes them spin; and if interrupts are threaded, spin_lock > > makes two threads run the same handler one by one. > > If you run on an SMP system and it happens that spin_lock_irqsave() just > immediately after spin_unlock(), you will get into the troubles. Am I mistaken? Hi Andy, Thanks for your reply. But I don't agree spin_lock_irqsave() just immediately after spin_unlock() could a problem on SMP. When the 1st cpu releases spinlock by spin_unlock, it has completed its section of accessing the critical data, then 2nd cpu gets the spin_lock. These two CPUs won't have overlap on accessing the same data. > > I think this entire activity is a carefully crafted mine field for the future > syzcaller and fuzzers alike. I don't believe there are no side effects in a > long > term on all possible systems and configurations (including forced threaded IRQ > handlers). Also I don't understand why forced threaded IRQ could be a problem. Since IRQ has been a thread, this actually makes the situation much simpler than non-threaded IRQ. Since all threads including those IRQ threads want to hold spin_lock, they won't access the same critical data at the same time either. > > I would love to see a better explanation in the commit message of such patches > which makes it clear that there are *no* side effects. > People had the same questions before, But I guess the discussion in this commit has led to a better commit log: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4eb7d0cd59 > For time being, NAK to the all patches of this kind. Fair enough, if you expect better explanation, I agree the commit log is too short. > > -- > With Best Regards, > Andy Shevchenko > Thanks Barry
On Wed, Feb 10, 2021 at 10:42 PM Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com> wrote: > > -----Original Message----- > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > Sent: Thursday, February 11, 2021 3:57 AM > > On Wed, Feb 10, 2021 at 11:50:45AM +0000, Song Bao Hua (Barry Song) wrote: > > > > -----Original Message----- > > > > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com] > > > > Sent: Wednesday, February 10, 2021 11:51 PM > > > > On Wed, Feb 10, 2021 at 5:43 AM luojiaxing <luojiaxing@huawei.com> wrote: > > > > > On 2021/2/9 17:42, Andy Shevchenko wrote: > > > > ... > > > > > > > Between IRQ handler A and IRQ handle A, it's no need for a SLIS. > > > > > > > > Right, but it's not the case in the patches you provided. > > > > > > The code still holds spin_lock. So if two cpus call same IRQ handler, > > > spin_lock makes them spin; and if interrupts are threaded, spin_lock > > > makes two threads run the same handler one by one. > > > > If you run on an SMP system and it happens that spin_lock_irqsave() just > > immediately after spin_unlock(), you will get into the troubles. Am I mistaken? > > Hi Andy, > Thanks for your reply. > > But I don't agree spin_lock_irqsave() just immediately after spin_unlock() > could a problem on SMP. > When the 1st cpu releases spinlock by spin_unlock, it has completed its section > of accessing the critical data, then 2nd cpu gets the spin_lock. These two CPUs > won't have overlap on accessing the same data. > > > > > I think this entire activity is a carefully crafted mine field for the future > > syzcaller and fuzzers alike. I don't believe there are no side effects in a > > long > > term on all possible systems and configurations (including forced threaded IRQ > > handlers). > > Also I don't understand why forced threaded IRQ could be a problem. Since IRQ has > been a thread, this actually makes the situation much simpler than non-threaded > IRQ. Since all threads including those IRQ threads want to hold spin_lock, > they won't access the same critical data at the same time either. > > > > > I would love to see a better explanation in the commit message of such patches > > which makes it clear that there are *no* side effects. > > > > People had the same questions before, But I guess the discussion in this commit > has led to a better commit log: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4eb7d0cd59 > > > For time being, NAK to the all patches of this kind. > > Fair enough, if you expect better explanation, I agree the commit log is too > short. Yes, my main concern that the commit message style as "I feel it's wrong" is inappropriate to this kind of patch. The one you pointed out above is better, you may give it even more thrust by explaining why it was in the first place and what happened between the driver gained this type of spinlock and your patch.
There is no need to use API with _irqsave in hard IRQ handler, So replace those with spin_lock. Luo Jiaxing (2): gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler() gpio: grgpio: Replace spin_lock_irqsave with spin_lock in grgpio_irq_handler() drivers/gpio/gpio-grgpio.c | 5 ++--- drivers/gpio/gpio-omap.c | 15 ++++++--------- 2 files changed, 8 insertions(+), 12 deletions(-)