Re: [PATCH v2] clocksource: timer-sp804: Fix an Oops when read_current_timer is called on ARM32 platforms where the SP804 is not registered as the sched_clock.

[Guenter Roeck]

Hi,

On Thu, Dec 25, 2025 at 04:16:31PM +0800, Stephen Eta Zhou wrote:
> On SP804, the delay timer shares the same clkevt instance with
> sched_clock.
> On some platforms, when sp804_clocksource_and_sched_clock_init
> is called with use_sched_clock not set to 1,
> sched_clkevt is not properly initialized. However,
> sp804_register_delay_timer is invoked unconditionally,
> and read_current_timer() subsequently calls sp804_read
> on an uninitialized sched_clkevt, leading to a kernel
> Oops when accessing sched_clkevt->value.
> 
> Declare a dedicated clkevt instance exclusively for delay timer,
> instead of sharing the same clkevt with sched_clock.
> This ensures that read_current_timer continues to work correctly
> regardless of whether SP804 is selected as the sched_clock.
> 
> Fixes: 640594a04f11 ("clocksource/drivers/timer-sp804: Fix read_current_timer() issue when clock source is not registered")
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
> Closes: https://lore.kernel.org/oe-kbuild-all/202512250520.APOMkYRQ-lkp@xxxxxxxxx/
> Signed-off-by: Stephen Eta Zhou <stephen.eta.zhou@xxxxxxxxx>

I found that the integratorcp qemu emulation still hangs unpredictably
with this and the preceding patch in the tree.

I have no idea what is causing the problem, except that it disappears if I
revert this patch and 640594a04f11.

It appears that no one else has reported the problem, which suggests to me
that no one cares. Given that, I'll stop testing the upstream kernel against
the integratorcp qemu emulation.

This is just informational; no action expected or warranted.

Thanks,
Guenter