Re: [PATCH v2 2/2] serial: amba-pl011: keep console clock enabled for atomic writes

On Mon 2026-07-27 14:05:50, John Ogness wrote:
> Hi Toshiyuki,
> 
> On 2026-07-27, "Toshiyuki Sato (Fujitsu)" <[email protected]> wrote:
> > Regarding Petr's comment [1] as well, I'm concerned about the
> > potential impact when the clk remains enabled during periods without
> > console output.
> 
> Can you elaborate on your concerns? Do you actually need such low-power
> _and_ kernel logging directly on serial?

Good point!

> > When creating nbcon patch, I saw a similar patch [2] from the past.
> > Have you considered coordinating with the clk subsystem implementation
> > for this?
> 
> AFAICT there was no real justification for enabling clocks per write
> other than because we can. A lot has changed since 2013 and neither
> spin_locks nor raw_spin_locks are appropriate because atomic printing
> can occur in _any_ context (including NMI's).
> 
> If the amba-pl011 insists on enabling clocks per write, I would
> recommend not implementing the write_atomic() callback. Since I assume a
> significant amount of users _will_ want atomic printing support, perhaps
> you can add a Kconfig to toggle building with clock-disabling and no
> atomic, or clock-always-on and atomic.
> 
> Note that there is also CON_NBCON_ATOMIC_UNSAFE available, if the driver
> wants to somehow blindly enable clocks on panic in order to unsafely
> dump panic logs.

I personally vote for removing the enable_clock()/disable_clock()
from the console->write_*() callbacks. It was an interesting power
optimization. But I believe that the chance to see kernel messages
in critical situations is more important.

Also I guess that the serial port is _not_ used on devices powered
by baterry in production. It might be used when debugging and
it is exatly the situation where the messages are important.

Best Regards,
Petr

> John Ogness
> 
> > [1] https://lore.kernel.org/all/[email protected]/
> > [2] https://lore.kernel.org/all/[email protected]/