lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ceed9ca5-d7e4-4a86-8af9-af3e87f1c70a@gmail.com>
Date: Sun, 13 Apr 2025 15:33:02 +0200
From: Emanuele Ghidoli <ghidoliemanuele@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 Linus Walleij <linus.walleij@...aro.org>,
 Francesco Dolcini <francesco@...cini.it>,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
 Emanuele Ghidoli <emanuele.ghidoli@...adex.com>, linux-gpio@...r.kernel.org,
 linux-kernel@...r.kernel.org, Marek Vasut <marek.vasut@...il.com>,
 stable@...r.kernel.org, Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: [PATCH v1] gpio: pca953x: fix IRQ storm on system wake up

On 07/04/2025 17:40, Andy Shevchenko wrote:
>> 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.
> 
# cat /sys/kernel/debug/irq/irqs/124

handler:  handle_level_irq


device:   (null)


status:   0x00000508


            _IRQ_NOPROBE


istate:   0x00004020


            IRQS_ONESHOT


ddepth:   0


wdepth:   0


dstate:   0x02402208


            IRQ_TYPE_LEVEL_LOW


            IRQD_LEVEL


            IRQD_ACTIVATED


            IRQD_IRQ_STARTED


            IRQD_DEFAULT_TRIGGER_SET


node:     0


affinity: 0-5


effectiv:


domain:  :soc:gpio@...00000


 hwirq:   0xb


 chip:    gpio-vf610


  flags:   0xa04


             IRQCHIP_MASK_ON_SUSPEND


             IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND


             IRQCHIP_IMMUTABLE


# cat /sys/kernel/debug/irq/irqs/209

handler:  handle_simple_irq


device:   (null)


status:   0x00008403


            _IRQ_NOPROBE


            _IRQ_NESTED_THREAD


istate:   0x00004000


ddepth:   0


wdepth:   0


dstate:   0x00400203


            IRQ_TYPE_EDGE_RISING


            IRQ_TYPE_EDGE_FALLING


            IRQD_ACTIVATED


            IRQD_IRQ_STARTED


node:     0


affinity: 0-5


effectiv:


domain:  :soc:bus@...00000:i2c@...40000:gpio-expander@29


 hwirq:   0x4


 chip:    3-0029


  flags:   0x800


             IRQCHIP_IMMUTABLE

And these just for confirmation (4 interrupt triggered by pushing the
SMARC_SLEEP# button):
# cat /proc/interrupts |grep 0029

124:          4          0          0          0          0          0
gpio-vf610  11 Level     3-0029

209:          0          4          0          0          0          0 3-0029
 4 Edge      SMARC_SLEEP#


# cat /sys/kernel/debug/wakeup_sources

name            active_count    event_count     wakeup_count    expire_count
 active_since    total_time      max_time        last_change
prevent_suspend_time
gpio-keys       4               4               0               0
 0               43              14              293116          0

>> 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.
> 
It took me a while to realize that the relevant information is only available
when CONFIG_GENERIC_IRQ_DEBUGFS is enabled.
All /sys/kernel/irq/*/wakeup always reports "disabled", even if wakeup is
actually configured. I guess if this is the information you were asking for.

Regards,
Emanuele


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ