Re: [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code

[Benedikt Spranger <b.spranger@linutronix.de>]

On Tue, 30 Jun 2026 17:35:59 +0100
Andrew Murray <amurray@thegoodpenguin.co.uk> wrote:

> The printk_delay and boot_delay features are helpful for debugging
> as kernel output can be slowed down during boot allowing messages to
> be seen before scrolling off the screen, or to correlate timing
> between some physical event and console output.
By now, it slows down the boot process, which is the handy part of that
feature.

> However, since the introduction of nbcon and the legacy printer thread
> for PREEMPT_RT kernels, printk records are now emited to the console
> asynchronously to the caller of printk. Thus, any printk delay added
> by boot_delay/printk_delay continues to slow down the calling process
> but may not have any impact to the rate in which records are emited
> to the console.
Using this feature to slow down the boot/suspend/resume process and
implicit make printk() happen, is the usefull part of that feature.
Imagine this sequence (which hit me on suspend/resume on i.MX after
shutting down all secondary CPUs)

  printk("A");
  (do some stuff)
  printk("B");
  read from peripheral --> system got stuck here since peripheral was
  not clocked or powered or both any more.

The delay (and later on a ugly patch to make printk() synchrounous)
helped to locate where the failed access happend. JTAG did not help,
since the CPU got stuck --> no JTAG communication to that CPU.

With your purposed change you *may* see "A", but never "B".
Quite challenging...

So please leave the delay on the calling side - it is helpfull there.

Regards
    Bene Spranger