| Message ID | 20250326173838.4617-1-francesco@dolcini.it |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] gpio: pca953x: fix IRQ storm on system wake up | expand |
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Wed, 26 Mar 2025 18:38:38 +0100, Francesco Dolcini wrote: > If an input changes state during wake-up and is used as an interrupt > source, the IRQ handler reads the volatile input register to clear the > interrupt mask and deassert the IRQ line. However, the IRQ handler is > triggered before access to the register is granted, causing the read > operation to fail. > > As a result, the IRQ handler enters a loop, repeatedly printing the > "failed reading register" message, until `pca953x_resume` is eventually > called, which restores the driver context and enables access to > registers. > > [...] Applied, thanks! [1/1] gpio: pca953x: fix IRQ storm on system wake up commit: 23334dfbeec89bf79f2ab893034b50612d039594 Best regards,
+Cc: Geert On Thu, Apr 03, 2025 at 02:07:05PM +0200, Bartosz Golaszewski wrote: > On Wed, 26 Mar 2025 18:38:38 +0100, Francesco Dolcini wrote: > > If an input changes state during wake-up and is used as an interrupt > > source, the IRQ handler reads the volatile input register to clear the > > interrupt mask and deassert the IRQ line. However, the IRQ handler is > > triggered before access to the register is granted, causing the read > > operation to fail. > > > > As a result, the IRQ handler enters a loop, repeatedly printing the > > "failed reading register" message, until `pca953x_resume` is eventually > > called, which restores the driver context and enables access to > > registers. [...] > Applied, thanks! Won't this regress as it happens the last time [1]? [1]: https://lore.kernel.org/linux-gpio/CAMuHMdVnKX23yi7ir1LVxfXAMeeWMFzM+cdgSSTNjpn1OnC2xw@mail.gmail.com/
On Thu, Apr 3, 2025 at 3:54 PM Andy Shevchenko <andriy.shevchenko@intel.com> wrote: > > +Cc: Geert > > On Thu, Apr 03, 2025 at 02:07:05PM +0200, Bartosz Golaszewski wrote: > > On Wed, 26 Mar 2025 18:38:38 +0100, Francesco Dolcini wrote: > > > > If an input changes state during wake-up and is used as an interrupt > > > source, the IRQ handler reads the volatile input register to clear the > > > interrupt mask and deassert the IRQ line. However, the IRQ handler is > > > triggered before access to the register is granted, causing the read > > > operation to fail. > > > > > > As a result, the IRQ handler enters a loop, repeatedly printing the > > > "failed reading register" message, until `pca953x_resume` is eventually > > > called, which restores the driver context and enables access to > > > registers. > > [...] > > > Applied, thanks! > > Won't this regress as it happens the last time [1]? > > [1]: https://lore.kernel.org/linux-gpio/CAMuHMdVnKX23yi7ir1LVxfXAMeeWMFzM+cdgSSTNjpn1OnC2xw@mail.gmail.com/ > Ah, good catch. I'm wondering what the right fix here is but don't really have any ideas at the moment. Any hints are appreciated. For now, I'm dropping it. Bart
On 03/04/2025 15:56, Bartosz Golaszewski wrote: > On Thu, Apr 3, 2025 at 3:54 PM Andy Shevchenko > <andriy.shevchenko@intel.com> wrote: >> >> +Cc: Geert >> >> On Thu, Apr 03, 2025 at 02:07:05PM +0200, Bartosz Golaszewski wrote: >>> On Wed, 26 Mar 2025 18:38:38 +0100, Francesco Dolcini wrote: >> >>>> If an input changes state during wake-up and is used as an interrupt >>>> source, the IRQ handler reads the volatile input register to clear the >>>> interrupt mask and deassert the IRQ line. However, the IRQ handler is >>>> triggered before access to the register is granted, causing the read >>>> operation to fail. >>>> >>>> As a result, the IRQ handler enters a loop, repeatedly printing the >>>> "failed reading register" message, until `pca953x_resume` is eventually >>>> called, which restores the driver context and enables access to >>>> registers. >> >> [...] >> >>> Applied, thanks! >> >> Won't this regress as it happens the last time [1]? >> >> [1]: https://lore.kernel.org/linux-gpio/CAMuHMdVnKX23yi7ir1LVxfXAMeeWMFzM+cdgSSTNjpn1OnC2xw@mail.gmail.com/ >> > > Ah, good catch. I'm wondering what the right fix here is but don't > really have any ideas at the moment. Any hints are appreciated. > > For now, I'm dropping it. > > Bart I’ve found another possible solution: disable the PCA953x IRQ in pca953x_suspend() and re-enable it in pca953x_resume(). This would prevent the ISR from being triggered while the regmap is in cache-only mode. The wake-up capability is preserved, since an IRQ can still wake the system even when disabled with disable_irq(), as long as it has wake enabled. This should avoid introducing regressions and still handle Geert’s use case properly. Andy, Bart, Geert - what do you think?
On Mon, Apr 07, 2025 at 05:11:14PM +0200, Emanuele Ghidoli wrote: > On 03/04/2025 15:56, Bartosz Golaszewski wrote: > > On Thu, Apr 3, 2025 at 3:54 PM Andy Shevchenko > > <andriy.shevchenko@intel.com> wrote: > >> > >> +Cc: Geert > >> > >> On Thu, Apr 03, 2025 at 02:07:05PM +0200, Bartosz Golaszewski wrote: > >>> On Wed, 26 Mar 2025 18:38:38 +0100, Francesco Dolcini wrote: > >> > >>>> If an input changes state during wake-up and is used as an interrupt > >>>> source, the IRQ handler reads the volatile input register to clear the > >>>> interrupt mask and deassert the IRQ line. However, the IRQ handler is > >>>> triggered before access to the register is granted, causing the read > >>>> operation to fail. > >>>> > >>>> As a result, the IRQ handler enters a loop, repeatedly printing the > >>>> "failed reading register" message, until `pca953x_resume` is eventually > >>>> called, which restores the driver context and enables access to > >>>> registers. [...] > >>> Applied, thanks! > >> > >> Won't this regress as it happens the last time [1]? > >> > >> [1]: https://lore.kernel.org/linux-gpio/CAMuHMdVnKX23yi7ir1LVxfXAMeeWMFzM+cdgSSTNjpn1OnC2xw@mail.gmail.com/ > >> > > > > Ah, good catch. I'm wondering what the right fix here is but don't > > really have any ideas at the moment. Any hints are appreciated. > > > > For now, I'm dropping it. > > > > Bart > > I’ve found another possible solution: disable the PCA953x IRQ in > pca953x_suspend() and re-enable it in pca953x_resume(). > This would prevent the ISR from being triggered while the regmap is in > cache-only mode. > The wake-up capability is preserved, since an IRQ can still wake the system > even when disabled with disable_irq(), as long as it has wake enabled. Can you enable IRQ debugfs and dump the state of the wake* nodes for the respective interrupts? In this case we will be 100% sure it works as expected. > This should avoid introducing regressions and still handle Geert’s use case > properly. > > Andy, Bart, Geert - what do you think? Sounds okay, but please double check the above.
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index d63c1030e6ac..d39bdc125cfc 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -1252,7 +1252,7 @@ static int pca953x_resume(struct device *dev) return ret; } -static DEFINE_SIMPLE_DEV_PM_OPS(pca953x_pm_ops, pca953x_suspend, pca953x_resume); +static DEFINE_NOIRQ_DEV_PM_OPS(pca953x_pm_ops, pca953x_suspend, pca953x_resume); /* convenience to stop overlong match-table lines */ #define OF_653X(__nrgpio, __int) ((void *)(__nrgpio | PCAL653X_TYPE | __int))