kernel/git/stable/linux-stable.git/drivers/clocksource, branch linux-6.1.y

clocksource/drivers/armada: Unwind timer clock on init failure

2026-09-14T11:25:35+00:00

[ Upstream commit 8b4127f6db40381229f3564d34ac35f36311c201 ] The Armada timer init paths enable their clock before calling the common initialization routine. If that routine returns an error, the clock is left enabled even though the timer was not initialized successfully. Fixes: 12549e27c63c ("clocksource/drivers/time-armada-370-xp: Convert init function to return error") Signed-off-by: Yuho Choi Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260802213545.565913-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin

clocksource/drivers/clps711x: Do not unmap clocksource MMIO

2026-09-14T11:25:35+00:00

[ Upstream commit e998c6300ef4e062a704ee17b5a812c0b595cf42 ] clps711x_clksrc_init() stores the timer base address in the static tcd pointer and registers it as both the clocksource MMIO address and the sched_clock read address. The clocksource init path must therefore keep the mapping alive after clps711x_timer_init() returns. However, the shared unmap_io exit path is also reached after successful clocksource registration, so the MMIO mapping is torn down while the clocksource and sched_clock readers may still access it. Return directly after successful clocksource registration and leave the mapping alive for the registered readers. Keep the unmap_io path for the error paths and for the clockevent init path. Fixes: cd32e596f02f ("clocksource/drivers/clps711x: Fix resource leaks in error paths") Signed-off-by: Guangshuo Li Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260704175451.256364-1-lgs201920130244@gmail.com Signed-off-by: Sasha Levin

clocksource/drivers/timer-sun4i: Advertise a real minimum delta

2026-09-14T11:24:05+00:00

commit d21808328225ab8cee46885bf9a0dffcefbe630e upstream. sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation. Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program") Reported-by: Indrek Kruusa Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Assisted-by: Codex:gpt-5.5 Signed-off-by: Felix Yan Signed-off-by: Daniel Lezcano Tested-by: Indrek Kruusa Acked-by: Jernej Skrabec Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Link: https://patch.msgid.link/20260624220434.4183732-1-felixonmars@archlinux.org Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/timer-tegra186: Fix support for multiple watchdog instances

2026-07-24T13:54:24+00:00

commit ca57bf46e7a94f8c53d05c376df9fcfdcb482100 upstream. Tegra SoCs support multiple watchdogs; currently only one (WDT0) is used. When multiple watchdogs are registered, tegra186_wdt_enable() overwrites the TKEIE(x) register, discarding any existing watchdog interrupt enable bits. As a result, enabling one watchdog inadvertently disables interrupts for the others. Fix this by preserving the existing TKEIE(x) value and updating it using a read-modify-write sequence. Fixes: 42cee19a9f83 ("clocksource: Add Tegra186 timers support") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Signed-off-by: Daniel Lezcano Reviewed-by: Jon Hunter Link: https://patch.msgid.link/20260507154557.2082697-2-kkartik@nvidia.com Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/timer-integrator-ap: Add missing Kconfig dependency on OF

2026-03-04T12:20:16+00:00

[ Upstream commit 2246464821e2820572e6feefca2029f17629cc50 ] This driver accesses the of_aliases global variable declared in linux/of.h and defined in drivers/base/of.c. It requires OF support or will cause a link failure. Add the missing Kconfig dependency. Closes: https://lore.kernel.org/oe-kbuild-all/202601152233.og6LdeUo-lkp@intel.com/ Signed-off-by: Bartosz Golaszewski Signed-off-by: Daniel Lezcano Link: https://patch.msgid.link/20260116111723.10585-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Sasha Levin

clocksource/drivers/sh_tmu: Always leave device running after probe

2026-03-04T12:20:16+00:00

[ Upstream commit b1278972b08e480990e2789bdc6a7c918bc349be ] The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe. Signed-off-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20251202221341.1856773-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Sasha Levin

riscv: clocksource: Fix stimecmp update hazard on RV32

2026-02-06T15:44:08+00:00

[ Upstream commit eaa9bb1d39d59e7c17b06cec12622b7c586ab629 ] On RV32, updating the 64-bit stimecmp (or vstimecmp) CSR requires two separate 32-bit writes. A race condition exists if the timer triggers during these two writes. The RISC-V Privileged Specification (e.g., Section 3.2.1 for mtimecmp) recommends a specific 3-step sequence to avoid spurious interrupts when updating 64-bit comparison registers on 32-bit systems: 1. Set the low-order bits (stimecmp) to all ones (ULONG_MAX). 2. Set the high-order bits (stimecmph) to the desired value. 3. Set the low-order bits (stimecmp) to the desired value. Current implementation writes the LSB first without ensuring a future value, which may lead to a transient state where the 64-bit comparison is incorrectly evaluated as "expired" by the hardware. This results in spurious timer interrupts. This patch adopts the spec-recommended 3-step sequence to ensure the intermediate 64-bit state is never smaller than the current time. Fixes: 9f7a8ff6391f ("RISC-V: Prefer sstc extension if available") Signed-off-by: Naohiko Shimizu Reviewed-by: Anup Patel Link: https://patch.msgid.link/20260104135938.524-2-naohiko.shimizu@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin

clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel

2025-12-06T21:12:17+00:00

[ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ] The driver uses the raw_readl() and raw_writel() functions. Those are not for MMIO devices. Replace them with readl() and writel() [ dlezcano: Fixed typo in the subject s/reald/readl/ ] Signed-off-by: Daniel Lezcano Acked-by: Arnd Bergmann Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20250804152344.1109310-2-daniel.lezcano@linaro.org Signed-off-by: Sasha Levin

clocksource/drivers/sp804: Do not use timer namespace for timer_shutdown() function

2025-10-29T13:04:32+00:00

[ Upstream commit 6e1fc2591f116dfb20b65cf27356475461d61bd8 ] A new "shutdown" timer state is being added to the generic timer code. One of the functions to change the timer into the state is called "timer_shutdown()". This means that there can not be other functions called "timer_shutdown()" as the timer code owns the "timer_*" name space. Rename timer_shutdown() to evt_timer_shutdown() to avoid this conflict. Signed-off-by: Steven Rostedt (Google) Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: Guenter Roeck Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Link: https://lkml.kernel.org/r/20221106212702.182883323@goodmis.org Link: https://lore.kernel.org/all/20221105060155.592778858@goodmis.org/ Link: https://lore.kernel.org/r/20221110064147.158230501@goodmis.org Link: https://lore.kernel.org/r/20221123201624.634354813@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/arm_arch_timer: Do not use timer namespace for timer_shutdown() function

2025-10-29T13:04:31+00:00

[ Upstream commit 73737a5833ace25a8408b0d3b783637cb6bf29d1 ] A new "shutdown" timer state is being added to the generic timer code. One of the functions to change the timer into the state is called "timer_shutdown()". This means that there can not be other functions called "timer_shutdown()" as the timer code owns the "timer_*" name space. Rename timer_shutdown() to arch_timer_shutdown() to avoid this conflict. Signed-off-by: Steven Rostedt (Google) Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: Guenter Roeck Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Acked-by: Marc Zyngier Link: https://lkml.kernel.org/r/20221106212702.002251651@goodmis.org Link: https://lore.kernel.org/all/20221105060155.409832154@goodmis.org/ Link: https://lore.kernel.org/r/20221110064146.981725531@goodmis.org Link: https://lore.kernel.org/r/20221123201624.574672568@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman