Message ID | 20241012105743.12450-1-matsievskiysv@gmail.com |
---|---|
Headers | show |
Series | pinctrl: ocelot: fix system hang on level based interrupts | expand |
On Sat, Oct 12, 2024 at 12:58 PM Sergey Matsievskiy <matsievskiysv@gmail.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@gmail.com> > Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Patch applied and tagged for stable! Yours, Linus Walleij
On Sat, Oct 12, 2024 at 01:57:43PM +0300, Sergey Matsievskiy wrote: ... > 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 > ``` Side note: `git grep ...` is much much faster if you have a Git tree at hand.
On Sat, Oct 12, 2024 at 10:04:30PM +0200, Linus Walleij wrote:
> Patch applied and tagged for stable!
Awesome, thanks!
--
Sergey Matsievskiy
On Sun, Oct 13, 2024 at 10:07:04PM +0300, Andy Shevchenko wrote:
> Side note: `git grep ...` is much much faster if you have a Git tree at hand.
Thanks for the tip! I usually use ripgrep, but git grep has some interesting
features.