Re: [PATCH] clocksource/drivers/timer-sun4i: Advertise a real minimum delta

[sashiko-bot@kernel.org]

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);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624220434.4183732-1-felixonmars@archlinux.org?part=1