All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: "Toshiyuki Sato (Fujitsu)" <fj6611ie@fujitsu.com>,
	'Karl Mehltretter' <kmehltretter@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-rt-devel@lists.linux.dev" <linux-rt-devel@lists.linux.dev>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Clark Williams <clrkwllms@kernel.org>
Subject: Re: [PATCH v2 2/2] serial: amba-pl011: keep console clock enabled for atomic writes
Date: Wed, 29 Jul 2026 13:09:36 +0200	[thread overview]
Message-ID: <amnfcOod6ayqfNda@pathway.suse.cz> (raw)
In-Reply-To: <87pl0863t5.fsf@jogness.linutronix.de>

On Mon 2026-07-27 14:05:50, John Ogness wrote:
> Hi Toshiyuki,
> 
> On 2026-07-27, "Toshiyuki Sato (Fujitsu)" <fj6611ie@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?

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/al4KdsU9YLOmwDoV@pathway.suse.cz/
> > [2] https://lore.kernel.org/all/1359475526-17523-1-git-send-email-walimisdev@gmail.com/

      parent reply	other threads:[~2026-07-29 11:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 21:33 [PATCH v2 0/2] serial: amba-pl011: fix console clock lifetime Karl Mehltretter
2026-07-24 21:33 ` [PATCH v2 1/2] serial: amba-pl011: unprepare console clock on unregister Karl Mehltretter
2026-07-24 21:55   ` sashiko-bot
2026-07-24 22:22     ` Karl Mehltretter
2026-07-24 21:33 ` [PATCH v2 2/2] serial: amba-pl011: keep console clock enabled for atomic writes Karl Mehltretter
2026-07-27  2:46   ` Toshiyuki Sato (Fujitsu)
2026-07-27 11:59     ` John Ogness
2026-07-28  0:26       ` Toshiyuki Sato (Fujitsu)
2026-07-29 11:09       ` Petr Mladek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amnfcOod6ayqfNda@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=bigeasy@linutronix.de \
    --cc=clrkwllms@kernel.org \
    --cc=fj6611ie@fujitsu.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=kmehltretter@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.