From: Linus Walleij <linus.walleij@linaro.org>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Alexandre Courbot <gnurou@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Lior Amsalem <alior@marvell.com>,
Tawfik Bayouk <tawfik@marvell.com>,
Nadav Haklai <nadavh@marvell.com>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH] gpio: mvebu: Fix mask/unmask managment per irq chip type
Date: Wed, 8 Apr 2015 16:35:48 +0200 [thread overview]
Message-ID: <CACRpkdYRnjE_26=yiA-dS9DYXgiLeA7zD8i7uxoZqotDcC+yMA@mail.gmail.com> (raw)
In-Reply-To: <1427987471-20419-1-git-send-email-gregory.clement@free-electrons.com>
On Thu, Apr 2, 2015 at 5:11 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Level IRQ handlers and edge IRQ handler are managed by tow different
> sets of registers. But currently the driver uses the same mask for the
> both registers. It lead to issues with the following scenario:
>
> First, an IRQ is requested on a GPIO to be triggered on front. After,
> this an other IRQ is requested for a GPIO of the same bank but
> triggered on level. Then the first one will be also setup to be
> triggered on level. It leads to an interrupt storm.
>
> The different kind of handler are already associated with two
> different irq chip type. With this patch the driver uses a private
> mask for each one which solves this issue.
>
> It has been tested on an Armada XP based board and on an Armada 375
> board. For the both boards, with this patch is applied, there is no
> such interrupt storm when running the previous scenario.
>
> This bug was already fixed but in a different way in the legacy
> version of this driver by Evgeniy Dushistov:
> 9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain
> sequence of request_irq can cause irq storm". The fact the new version
> of the gpio drive could be affected had been discussed there:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012
>
> Reported-by: Evgeniy A. Dushistov <dushistov@mail.ru>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Cc: <stable@vger.kernel.org> # v3.7 +
Patch applied.
Yours,
Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] gpio: mvebu: Fix mask/unmask managment per irq chip type
Date: Wed, 8 Apr 2015 16:35:48 +0200 [thread overview]
Message-ID: <CACRpkdYRnjE_26=yiA-dS9DYXgiLeA7zD8i7uxoZqotDcC+yMA@mail.gmail.com> (raw)
In-Reply-To: <1427987471-20419-1-git-send-email-gregory.clement@free-electrons.com>
On Thu, Apr 2, 2015 at 5:11 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Level IRQ handlers and edge IRQ handler are managed by tow different
> sets of registers. But currently the driver uses the same mask for the
> both registers. It lead to issues with the following scenario:
>
> First, an IRQ is requested on a GPIO to be triggered on front. After,
> this an other IRQ is requested for a GPIO of the same bank but
> triggered on level. Then the first one will be also setup to be
> triggered on level. It leads to an interrupt storm.
>
> The different kind of handler are already associated with two
> different irq chip type. With this patch the driver uses a private
> mask for each one which solves this issue.
>
> It has been tested on an Armada XP based board and on an Armada 375
> board. For the both boards, with this patch is applied, there is no
> such interrupt storm when running the previous scenario.
>
> This bug was already fixed but in a different way in the legacy
> version of this driver by Evgeniy Dushistov:
> 9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain
> sequence of request_irq can cause irq storm". The fact the new version
> of the gpio drive could be affected had been discussed there:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012
>
> Reported-by: Evgeniy A. Dushistov <dushistov@mail.ru>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Cc: <stable@vger.kernel.org> # v3.7 +
Patch applied.
Yours,
Linus Walleij
next prev parent reply other threads:[~2015-04-08 14:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 15:11 [PATCH] gpio: mvebu: Fix mask/unmask managment per irq chip type Gregory CLEMENT
2015-04-02 15:11 ` Gregory CLEMENT
2015-04-08 14:35 ` Linus Walleij [this message]
2015-04-08 14:35 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACRpkdYRnjE_26=yiA-dS9DYXgiLeA7zD8i7uxoZqotDcC+yMA@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gnurou@gmail.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=nadavh@marvell.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.