[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbCVFEgP3ZchLtM8KgDVVbCiK7ZgGha=iVfTBveRstDkA@mail.gmail.com>
Date: Sat, 12 Oct 2024 22:04:30 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Sergey Matsievskiy <matsievskiysv@...il.com>
Cc: alexandre.belloni@...tlin.com, quentin.schulz@...tlin.com,
lars.povlsen@...rochip.com, horatiu.vultur@...rochip.com,
andriy.shevchenko@...ux.intel.com, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH v2 1/1] pinctrl: ocelot: fix system hang on level based interrupts
On Sat, Oct 12, 2024 at 12:58 PM Sergey Matsievskiy
<matsievskiysv@...il.com> wrote:
> The current implementation only calls chained_irq_enter() and
> chained_irq_exit() if it detects pending interrupts.
>
> ```
> for (i = 0; i < info->stride; i++) {
> uregmap_read(info->map, id_reg + 4 * i, ®);
> if (!reg)
> continue;
>
> chained_irq_enter(parent_chip, desc);
> ```
>
> However, in case of GPIO pin configured in level mode and the parent
> controller configured in edge mode, GPIO interrupt might be lowered by the
> hardware. In the result, if the interrupt is short enough, the parent
> interrupt is still pending while the GPIO interrupt is cleared;
> chained_irq_enter() never gets called and the system hangs trying to
> service the parent interrupt.
>
> Moving chained_irq_enter() and chained_irq_exit() outside the for loop
> ensures that they are called even when GPIO interrupt is lowered by the
> hardware.
>
> The similar code with chained_irq_enter() / chained_irq_exit() functions
> wrapping interrupt checking loop may be found in many other drivers:
> ```
> grep -r -A 10 chained_irq_enter drivers/pinctrl
> ```
>
> Signed-off-by: Sergey Matsievskiy <matsievskiysv@...il.com>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@...tlin.com>
Patch applied and tagged for stable!
Yours,
Linus Walleij
Powered by blists - more mailing lists