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

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")
Cc: stable@vger.kernel.org
Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com>
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 <felixonmars@archlinux.org>
---
 drivers/clocksource/timer-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] The exact same zero-tick interval bug fixed in timer-sun4i.c is present and unfixed in the sibling driver timer-sun5i.c.
- [High] The tick_resume callback can cause an infinite loop and hard lockup if the timer IP loses state during suspend.
- [High] sun4i_clkevt_set_oneshot() enables the hardware timer without programming a safe interval, which can cause a boot hang if the hardware interval register defaults to zero.
--

commit 58b9ac36774c7659ade7328ca0fd561f9759e49e
Author: Felix Yan <felixonmars@archlinux.org>
Subject: clocksource/drivers/timer-sun4i: Advertise a real minimum delta

This commit modifies the sun4i timer driver to advertise one extra tick for
the minimum delta. This prevents the clockevents core from requesting a
next event of exactly TIMER_SYNC_TICKS, which would result in programming a
zero-tick interval and hanging the hardware on Allwinner D1.

Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/

> diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c
> index 7bdcc60ad43cb..c2d04ab7cf2d3 100644
> --- a/drivers/clocksource/timer-sun4i.c
> +++ b/drivers/clocksource/timer-sun4i.c
> @@ -208,7 +208,7 @@ static int __init sun4i_timer_init(struct device_node *node)
>  	sun4i_timer_clear_interrupt(timer_of_base(&to));
>  
>  	clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
> -					TIMER_SYNC_TICKS, 0xffffffff);
> +					TIMER_SYNC_TICKS + 1, 0xffffffff);

[Severity: High]
This is a pre-existing issue, but the exact same zero-tick interval bug
appears to be present in the sibling driver timer-sun5i.c.

In drivers/clocksource/timer-sun5i.c:sun5i_setup_clockevent(), the device
is registered with a minimum delta of TIMER_SYNC_TICKS:

    clockevents_config_and_register(&ce->clkevt, rate,
                                    TIMER_SYNC_TICKS, 0xffffffff);

When the clockevents core requests exactly this length,
sun5i_clkevt_next_event() subtracts TIMER_SYNC_TICKS, resulting in 0:

    sun5i_clkevt_time_setup(ce, 0, evt - TIMER_SYNC_TICKS);

Should timer-sun5i.c be brought up to parity to prevent an identically
triggered hang there?


[Severity: High]
This isn't a bug introduced by this patch, but could this zero-tick hardware
hang also trigger via the oneshot configuration path in timer-sun4i.c?

When the clockevents core switches the timer state,
sun4i_clkevt_set_oneshot() calls:

    sun4i_clkevt_time_start(timer_of_base(to), 0, false);

This enables the timer without programming a valid non-zero interval, which
reloads the current uninitialized value of TIMER_INTVAL_REG(0).

If this defaults to 0 (the power-on reset default), does this risk the exact
same hardware hang?


[Severity: High]
This is a pre-existing issue, but can the timer sync logic cause a hard
lockup during system resume?

In drivers/clocksource/timer-sun4i.c, the tick_resume callback is mapped to
sun4i_clkevt_shutdown:

    .tick_resume = sun4i_clkevt_shutdown,

This calls sun4i_clkevt_time_stop() followed by sun4i_clkevt_sync(), which
spins infinitely waiting for Timer 1 to advance:

    while ((old - readl(base + TIMER_CNTVAL_REG(1))) < TIMER_SYNC_TICKS)
            cpu_relax();

If the timer block lost power during system suspend, Timer 1 will be
disabled upon resume. Since there is no suspend/resume hook to restart
Timer 1, the counter will never change.

Will this result in a deadlock?

>  
>  	/* Enable timer0 interrupt */
>  	val = readl(timer_of_base(&to) + TIMER_IRQ_EN_REG);
  

Hi Felix,

On Thu, 25 Jun 2026 06:04:34 +0800, Felix Yan wrote:
> 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")
> Cc: stable@vger.kernel.org
> Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com>
> 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 <felixonmars@archlinux.org>
> ---
>  drivers/clocksource/timer-sun4i.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c
> index 7bdcc60ad43c..c2d04ab7cf2d 100644
> --- a/drivers/clocksource/timer-sun4i.c
> +++ b/drivers/clocksource/timer-sun4i.c
> @@ -208,7 +208,7 @@ static int __init sun4i_timer_init(struct device_node *node)
>  	sun4i_timer_clear_interrupt(timer_of_base(&to));
>  
>  	clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
> -					TIMER_SYNC_TICKS, 0xffffffff);
> +					TIMER_SYNC_TICKS + 1, 0xffffffff);
>  
>  	/* Enable timer0 interrupt */
>  	val = readl(timer_of_base(&to) + TIMER_IRQ_EN_REG);
> -- 
> 2.54.0

I can confirm that this patch makes my Allwinner D1 board boot
again with v7.1-rc1 and newer kernels.

Tested-by: Indrek Kruusa <indrek.kruusa@gmail.com>
Closes also: https://lore.kernel.org/regressions/20260531165138.2696250-1-indrek.kruusa@gmail.com/

Thank you,
Indrek
  

Dne četrtek, 25. junij 2026 ob 00:04:34 Srednjeevropski poletni čas je Felix Yan napisal(a):
> 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")
> Cc: stable@vger.kernel.org
> Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com>
> 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 <felixonmars@archlinux.org>

Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej