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]?
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.