[Linux-stm32] [PATCH v2 0/3] Fix NXP STM clockevent bugs causing lockups

[Enric Balletbo i Serra]

Hi Sebastian,

Thank you for the review.

On Tue, Nov 3, 2026 at 4:42 PM Sebastian Andrzej Siewior
<bigeasy at linutronix.de> wrote:
>
> On 2026-11-02 22:16:19 [+0100], Enric Balletbo i Serra wrote:
> > This series fixes three bugs in the NXP STM clocksource driver that can
> > cause soft lockups and missed timer events, particularly visible on
> > PREEMPT_RT kernels running on S32G platforms.
> >
> > The NXP STM generates an interrupt only on exact match between the
> > counter and comparator registers. If the counter passes the programmed
> > value, the match is missed and the hardware must count through all 2^32
> > ticks (~32.2s at 133 MHz) before firing, causing soft lockups.
> >
> > Patch 1 fixes max_delta: on 64-bit platforms, ULONG_MAX exceeds the
> > hardware's 32-bit compare register width, making it possible to program
> > an unreachable compare value.
>
> This looks fine
>
> > Patch 2 fixes the overshoot detection in set_next_event: the existing
> > check only detected counter wraps, not the normal case where the counter
> > advances past the programmed value during the read-modify-write window.
> > Replace it with a signed comparison following the pattern used by
> > timer-imx-gpt.
>
> okay…
>
> > Patch 3 increases min_delta from 2us to 20us: under bus contention on
> > PREEMPT_RT, 2us is not enough margin and the counter frequently
> > overshoots the programmed value, triggering repeated -ETIME retries.
>
> This all sounds like the hpet trouble on x86. I'm not sure what heavy
> busy contention means and why the device is enabled/ disable during
> setting. I would assume that the programmed value hits the HW after the
> wrap so you wait until the counter wraps again for the equal match.
> Worst case would be you read back the expected value but the HW sees it
> later (after the wrap).
> hpet_clkevt_set_next_event() does in principle the same check as you in
> #2 except it compares against the "min" value instead <=0.
> Would this make sense?
>

Yes, it does make sense. I will look at the pattern used in hpet and
send a new version.

Thanks,
  Enric

> Sebastian
>