Re: [PATCH v4 1/1] printk: fix zero-valued printk timestamps in early boot

Roberto A. Foglietta
2026-04-14T09:51:59Z

On Tue, 14 Apr 2026 at 09:03, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Tim,
>
> Thanks for your patch!
>
> On Fri, 10 Apr 2026 at 22:38, Tim Bird <tim.bird@sony.com> wrote:
> > During early boot, printk timestamps are reported as zero before
> > kernel timekeeping starts (i.e. before time_init()). This
...
> Won't it be hard to see where the discontinuity happens in some cases?
> Perhaps this can be made more obvious by not doing the time conversion
> in kernelspace, like in your first version?
>
> > Signed-off-by: Tim Bird <tim.bird@sony.com>
>
> > --- /dev/null
> > +++ b/include/linux/early_times.h
>
> > +/* returns a nanosecond value based on early cycles */
> > +static inline u64 early_times_ns(void)
> > +{
> > + if (CONFIG_EARLY_CYCLES_KHZ)
> > + /*
> > + * Note: the multiply must precede the division to avoid
> > + * truncation and loss of resolution
> > + * Don't use fancier MULT/SHIFT math here. Since this is
> > + * static, the compiler can optimize the math operations.
> > + */
> > + return (early_unsafe_cycles() * NS_PER_KHZ) / CONFIG_EARLY_CYCLES_KHZ;
>
> Still, this contains a 64-by-32 division, so let's see how this works
> out on 32-bit (RISCV_TIMER is set on rv32!). If the compiler would
> generate a function call to a libgcc helper, you will have to switch
> to the mul_u64_u32_div() helper...

Interesting.

https://github.com/robang74/uchaosys/blob/53e72d169/cnfg/printk-fix-early-boot-timestamps-patch-v4.txt#L92

Elvis the King (A?:), R-