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

[Toshiyuki Sato (Fujitsu)]

Hi John,

Thank you for your comments.

> On 2026-07-27, "Toshiyuki Sato (Fujitsu)" <fj6611ie at fujitsu.com> 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?

Nothing specific comes to mind.
There was a similar patch in the past, and the maintainers at that time
left some comments, so I thought they might be useful as a reference.

> 
> > 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.

Thank you for the explanation.
If the conclusion is that this is no longer something we need to worry about,
then I don’t have any further comments.

Thanks,
Toshiyuki Sato

> 
> John Ogness
> 
> > [1] https://lore.kernel.org/all/al4KdsU9YLOmwDoV@pathway.suse.cz/
> > [2]
> https://lore.kernel.org/all/1359475526-17523-1-git-send-email-walimisdev@gmail.
> com/