kernel/linux.git/drivers/counter, branch v6.6.132

counter: interrupt-cnt: Drop IRQF_NO_THREAD flag

2026-01-17T15:29:53+00:00

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 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 Reviewed-by: Sebastian Andrzej Siewior Reviewed-by: Oleksij Rempel Link: https://lore.kernel.org/r/20251118083603.778626-1-alexander.sverdlin@siemens.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

counter: 104-quad-8: Fix incorrect return value in IRQ handler

2026-01-17T15:29:52+00:00

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 Signed-off-by: Haotian Zhang Link: https://lore.kernel.org/r/20251215020114.1913-1-vulab@iscas.ac.cn Cc: stable@vger.kernel.org Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

counter: interrupt-cnt: Protect enable/disable OPs with mutex

2025-06-19T13:28:31+00:00

[ Upstream commit 7351312632e831e51383f48957d47712fae791ef ] 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 Fixes: a55ebd47f21f ("counter: add IRQ or GPIO based counter") Acked-by: Oleksij Rempel Link: https://lore.kernel.org/r/20250331163642.2382651-1-alexander.sverdlin@siemens.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin

counter: microchip-tcb-capture: Fix undefined counter channel state on probe

2025-04-07T08:06:37+00:00

commit c0c9c73434666dc99ee156b25e7e722150bee001 upstream. Hardware initialize of the timer counter channel does not occur on probe thus leaving the Count in an undefined state until the first function_write() callback is executed. Fix this by performing the proper hardware initialization during probe. Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Reported-by: Csókás Bence Closes: https://lore.kernel.org/all/bfa70e78-3cc3-4295-820b-3925c26135cb@prolan.hu/ Link: https://lore.kernel.org/r/20250305-preset-capture-mode-microchip-tcb-capture-v1-1-632c95c6421e@kernel.org Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

counter: stm32-lptimer-cnt: fix error handling when enabling

2025-04-07T08:06:37+00:00

commit 8744dcd4fc7800de2eb9369410470bb2930d4c14 upstream. In case the stm32_lptim_set_enable_state() fails to update CMP and ARR, a timeout error is raised, by regmap_read_poll_timeout. It may happen, when the lptimer runs on a slow clock, and the clock is gated only few times during the polling. Badly, when this happen, STM32_LPTIM_ENABLE in CR register has been set. So the 'enable' state in sysfs wrongly lies on the counter being correctly enabled, due to CR is read as one in stm32_lptim_is_enabled(). To fix both issues: - enable the clock before writing CMP, ARR and polling ISR bits. It will avoid the possible timeout error. - clear the ENABLE bit in CR and disable the clock in the error path. Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer") Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20250224170657.3368236-1-fabrice.gasnier@foss.st.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

counter: ti-ecap-capture: Add check for clk_enable()

2024-12-09T09:32:37+00:00

[ Upstream commit 1437d9f1c56fce9c24e566508bce1d218dd5497a ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: 4e2f42aa00b6 ("counter: ti-ecap-capture: capture driver support for ECAP") Reviewed-by: Julien Panis Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20241104194059.47924-1-jiashengjiangcool@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin

counter: stm32-timer-cnt: Add check for clk_enable()

2024-12-09T09:32:37+00:00

[ Upstream commit 842c3755a6bfbfcafa4a1438078d2485a9eb1d87 ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: c5b8425514da ("counter: stm32-timer-cnt: add power management support") Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20241104191825.40155-1-jiashengjiangcool@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin

counter: ti-eqep: enable clock at probe

2024-07-05T07:33:56+00:00

[ Upstream commit 0cf81c73e4c6a4861128a8f27861176ec312af4e ] The TI eQEP clock is both a functional and interface clock. Since it is required for the device to function, we should be enabling it at probe. Up to now, we've just been lucky that the clock was enabled by something else on the system already. Fixes: f213729f6796 ("counter: new TI eQEP driver") Reviewed-by: Judith Mendez Signed-off-by: David Lechner Link: https://lore.kernel.org/r/20240621-ti-eqep-enable-clock-v2-1-edd3421b54d4@baylibre.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin

Merge tag 'counter-fixes-for-6.6a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus

2023-10-02T11:13:15+00:00

William writes: First set of Counter fixes for 6.6 The counter_get_ext() function would incorrectly refer to the first element of the extensions array to handle component array extensions when they are located at a different index; a fix is provided to index to the correct element in the array for this case. A fix for the microchip-tcb-capture is provided as well to correct an inverted internal GCLK logic for clock selection. * tag 'counter-fixes-for-6.6a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: microchip-tcb-capture: Fix the use of internal GCLK logic counter: chrdev: fix getting array extensions

counter: microchip-tcb-capture: Fix the use of internal GCLK logic

2023-09-05T16:25:14+00:00

As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should be set to 0 while using the internal GCLK (TIMER_CLOCK1). Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") Signed-off-by: Dharma Balasubiramani Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com Signed-off-by: William Breathitt Gray