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

[Roberto A. Foglietta]

On Fri, 17 Apr 2026 at 12:41, Petr Mladek <pmladek@xxxxxxxx> wrote:
>
...
> IMHO, the main risk is that it won't be used just by the 50 developers
> but it will get misused and open some can of worms. I think that
> the risk might be acceptable but...
>
> What do you think, please?

There are two different topics here and confusion arises from not
separating them:

1. Having a monotonic timestamp fully reliable and ASAP after the
kernel takes the control, is a great feature. Period.

2. Few people but relevant ones, those need to port the kernel on
prototypes that later will be products (hopefully).

The #1 goes in the kernel, following strictly the rules of the coding
/ janitoring. Period.

The #2 cannot go into the kernel tree but it is inheterly doomed to be
an out-of-tree entry point for "few people". Simply because it servers
those for which they are working "before" the kernel (early times, not
just about boot but kernel porting). In such a condition, the kernel
might oops soon after the boot without even reaching the timekeeper
calibration. As per first look or last resort, printing cycles (or any
other values as much as possible tight with the hardware) is the only
feasible approach.

A link (to this m-list repository) avoid repetitions, the V6 is much
better and more useful that a bunch of #ifdef / #else in the printk.c:

V6 ~> https://lkml.org/lkml/2026/4/16/441

How to settle down the debate about #1 and #2. Recognising that the #1
is a kernel feature, the #2 is a "before" the kernel thus out-of-three
approach for few but relevant people. Why offer to these "few but
relevant people" an entry point with essential directives, a fenced
read of a register, available for many arch in the same local header?
It costs almost nothing in terms of maintainability and provides a
universal way to face the same-old-issue of having something useful
rather than zero in early boot.

It costs almost nothing because it is essential and it is not supposed
to grow or be refined: essential is essential. Moreover, we cannot
develop for boards that did not exist yet, but essentials remain
valid, at least as a concept. It is clearly something out-of-the-three
because #include "early-times.h" and it is clearly something that it
is for advanced debugging and hacking (proper menuconfig placement),
thus not a feature but "essential as service".

Value (in terms of market)? Just a matter of perception: we know you
are out there, few and messy down in some portings, here you are our
2cents for you. In less modern terms: welcoming, as custom courtesy.
Is it relevant to add? Everyone that can port the kernel can do it in
their own way. It is relevant to recognise that #2 is not #1, anyway
even when #1 will solve the issue for every product out there.

Best regards, R-