commit 23f9485510c338476b9735d516c1d4aacb810d46 upstream.
An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as
CONFIG_PROVE_RAW_LOCK_NESTING warns:
=============================
[ BUG: Invalid wait context ]
6.18.0-rc1+git... #1
-----------------------------
some-user-space-process/1251 is trying to lock:
(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]
other info that might help us debug this:
context-{2:2}
no locks held by some-user-space-process/....
stack backtrace:
CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT
Call trace:
show_stack (C)
dump_stack_lvl
dump_stack
__lock_acquire
lock_acquire
_raw_spin_lock_irqsave
counter_push_event [counter]
interrupt_cnt_isr [interrupt_cnt]
__handle_irq_event_percpu
handle_irq_event
handle_simple_irq
handle_irq_desc
generic_handle_domain_irq
gpio_irq_handler
handle_irq_desc
generic_handle_domain_irq
gic_handle_irq
call_on_irq_stack
do_interrupt_handler
el0_interrupt
__el0_irq_handler_common
el0t_64_irq_handler
el0t_64_irq
... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an
alternative to switching to raw_spinlock_t, because the latter would limit
all potential nested locks to raw_spinlock_t only.
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20251117151314.xwLAZrWY@linutronix.de/
Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20251118083603.778626-1-alexander.sverdlin@siemens.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9517d76dd160208b7a432301ce7bec8fc1ddc305 upstream.
quad8_irq_handler() should return irqreturn_t enum values, but it
directly returns negative errno codes from regmap operations on error.
Return IRQ_NONE if the interrupt status cannot be read. If clearing the
interrupt fails, return IRQ_HANDLED to prevent the kernel from disabling
the IRQ line due to a spurious interrupt storm. Also, log these regmap
failures with dev_WARN_ONCE.
Fixes: 98ffe0252911 ("counter: 104-quad-8: Migrate to the regmap API")
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/r/20251215020114.1913-1-vulab@iscas.ac.cn
Cc: stable@vger.kernel.org
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark the interrupt as IRQF_SHARED to permit multiple counter channels to
share the same TCB IRQ line.
Each Timer/Counter Block (TCB) instance shares a single IRQ line among its
three internal channels. When multiple counter channels (e.g., counter@0
and counter@1) within the same TCB are enabled, the second call to
devm_request_irq() fails because the IRQ line is already requested by the
first channel.
Cc: stable@vger.kernel.org
Fixes: e5d581396821 ("counter: microchip-tcb-capture: Add IRQ handling")
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
Reviewed-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Reviewed-by: Bence Csókás <bence98@sch.bme.hu>
Link: https://lore.kernel.org/r/20251006-microchip-tcb-v1-1-09c19181bb4a@microchip.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
There is no need to register a manual `devm` action for `pm_runtime_disable()` when `devm_pm_runtime_enable()` exists. It does the same thing (but also calls `pm_runtime_dont_use_autosuspend()`, which should be fine here). Moreover, when `devm_add_action_or_reset()` fails, it is due to a failed memory allocation and will thus return `-ENOMEM`. `dev_err_probe()` doesn't do anything when error is `-ENOMEM`. Therefore, the call to `dev_err_probe()` is useless. Note that `devm_pm_runtime_enable()` has a tail call to `devm_add_action_or_reset()` and thus returns that value. Therefore, replace `dev_err_probe()` with the returning value. Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/pnda54bjmij.a.out@axis.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
William writes: Second set of Counter updates for 6.16 Adds compatible for STM32MP25 SoC and enables respective encoder capability for stm32-timer-cnt. Implements watch_validate callback for microchip-tcb-capture. * tag 'counter-updates-for-6.16b' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: microchip-tcb-capture: Add watch validation support counter: stm32-timer-cnt: add support for stm32mp25
The Timer Counter Block (TCB) exposes several kinds of events to the Counter framework, but not every event is meaningful on every hardware channel. Add a `watch_validate()` callback so userspace may register only the combinations actually supported: * Channel 0 (COUNTER_MCHP_EVCHN_CV, COUNTER_MCHP_EVCHN_RA) - COUNTER_EVENT_CAPTURE - COUNTER_EVENT_CHANGE_OF_STATE - COUNTER_EVENT_OVERFLOW * Channel 1 (COUNTER_MCHP_EVCHN_RB) - COUNTER_EVENT_CAPTURE * Channel 2 (COUNTER_MCHP_EVCHN_RC) - COUNTER_EVENT_THRESHOLD Any other request is rejected with `-EINVAL`. Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Link: https://lore.kernel.org/r/20250520-counter-tcb-v3-1-4631e2aff7ed@microchip.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
William writes: Counter updates for 6.16 An update to allow for larger count values in interrupt-cnt. * tag 'counter-updates-for-6.16' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: interrupt-cnt: Convert atomic_t -> atomic_long_t
Add support for STM32MP25 SoC. There are new counter modes that may be implemented in later. Still, use newly introduced compatible to handle this new HW variant and avoid being blocked with existing compatible in SoC dtsi file. Modes supported currently still remains compatible. New timer 20 has encoder capability, add it to the list. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20250110091922.980627-4-fabrice.gasnier@foss.st.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Enable/disable seems to be racy on SMP, consider the following scenario:
CPU0 CPU1
interrupt_cnt_enable_write(true)
{
if (priv->enabled == enable)
return 0;
if (enable) {
priv->enabled = true;
interrupt_cnt_enable_write(false)
{
if (priv->enabled == enable)
return 0;
if (enable) {
priv->enabled = true;
enable_irq(priv->irq);
} else {
disable_irq(priv->irq)
priv->enabled = false;
}
enable_irq(priv->irq);
} else {
disable_irq(priv->irq);
priv->enabled = false;
}
The above would result in priv->enabled == false, but IRQ left enabled.
Protect both write (above race) and read (to propagate the value on SMP)
callbacks with a mutex.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter")
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20250331163642.2382651-1-alexander.sverdlin@siemens.com
Signed-off-by: William Breathitt Gray <wbg@kernel.org>
Convert the internal counter type to atomic_long_t, which: - doesn't change much for existing in-tree users as they are 32-bit anyway (stm32/i.MX6) - doesn't introduce performace penalty on 32-bit platforms - provides 64-bit resolution on 64-bit platforms with virtually no preformance penalty Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20250331152222.2263776-1-alexander.sverdlin@siemens.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>