[PATCH 0/2] serial: amba-pl011: fix console clock lifetime

[PATCH 0/2] serial: amba-pl011: fix console clock lifetime

[Karl Mehltretter]

Patch 1 fixes an independent bug: pl011_console_setup() prepares the UART
clock but nothing releases it when the console is unregistered, so the
clock's prepare count leaks one reference per registration cycle (via
the sysfs "console" attribute or a driver unbind). It adds the missing
console .exit() and stands on its own.

Patch 2 fixes a PREEMPT_RT failure: pl011_console_write_atomic() runs in
nbcon atomic context but calls clk_enable(), which under RT can acquire a
sleeping lock, so an atomic-context printk on a clk-backed pl011 can hit
"sleeping function called from invalid context". The same lock
acquisition would also be unsafe if write_atomic() is invoked from NMI
context. It keeps the clock enabled while the console is registered and
releases it in .exit(); it depends on patch 1.

Tested on QEMU: the prepare-count leak was reproduced and fixed on
bcm2835 (a gateable CPRMAN UART clock), and the PREEMPT_RT splat was
reproduced and fixed on versatilepb. With the series applied, recycling
the console via the sysfs attribute keeps both the prepare and enable
counts balanced, and the console keeps working after re-registration.

Karl Mehltretter (2):
  serial: amba-pl011: unprepare console clock on unregister
  serial: amba-pl011: keep console clock enabled for atomic writes

 drivers/tty/serial/amba-pl011.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

-- 
2.53.0

[PATCH 1/2] serial: amba-pl011: unprepare console clock on unregister

[Karl Mehltretter]

pl011_console_setup() calls clk_prepare() on the UART clock, but the
console provides no matching teardown, so the clock is never unprepared
when the console is unregistered -- via the sysfs "console" attribute or
a driver unbind. Each re-registration prepares the clock again, leaking
one prepare reference per cycle.

Even where preparing the clock has no hardware effect, the stale
reference leaves the clock framework's prepare count unbalanced. On
providers whose prepare operation enables hardware, the leaked reference
may also keep the UART clock running after unregister.

Add a console .exit() callback that clk_unprepare()s the clock,
balancing the clk_prepare() in pl011_console_setup().

Fixes: 4b4851c65d92 ("clk: amba-pl011: convert to clk_prepare()/clk_unprepare()")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
The i.MX console had the same missing teardown, fixed in 9768a37cec37
("serial: imx: disable console clocks on unregister").

Measured on QEMU raspi (bcm2835), whose UART clock is a real gateable
CPRMAN clock: recycling the console via /sys/class/tty/ttyAMA0/console,
the uart clock's prepare_count (/sys/kernel/debug/clk/uart/
clk_prepare_count) climbs by one per cycle -- 2 -> 8 over six cycles --
without this patch, and stays at 2 with it.

 drivers/tty/serial/amba-pl011.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 8ed91e1da22b..1aa43994a3cd 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2552,6 +2552,15 @@ static int pl011_console_setup(struct console *co, char *options)
 	return uart_set_options(&uap->port, co, baud, parity, bits, flow);
 }
 
+static int pl011_console_exit(struct console *co)
+{
+	struct uart_amba_port *uap = amba_ports[co->index];
+
+	clk_unprepare(uap->clk);
+
+	return 0;
+}
+
 /**
  *	pl011_console_match - non-standard console matching
  *	@co:	  registering console
@@ -2705,6 +2714,7 @@ static struct console amba_console = {
 	.name		= "ttyAMA",
 	.device		= uart_console_device,
 	.setup		= pl011_console_setup,
+	.exit		= pl011_console_exit,
 	.match		= pl011_console_match,
 	.write_atomic	= pl011_console_write_atomic,
 	.write_thread	= pl011_console_write_thread,
-- 
2.53.0

Re: [PATCH 1/2] serial: amba-pl011: unprepare console clock on unregister

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing NULL check for `uap` in console callbacks leads to kernel panic if `uart_add_one_port` fails.
--

--- Patch [1]: [PATCH 1/2] serial: amba-pl011: unprepare console clock on unregister ---
commit 7c5636c95e763ddaf7574887aeb1e24ce1d44fec
Author: Karl Mehltretter <kmehltretter@gmail.com>

serial: amba-pl011: unprepare console clock on unregister

This patch adds a console .exit() callback that calls clk_unprepare() on the
UART clock when the console is unregistered. This balances the clk_prepare()
called in pl011_console_setup().

> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 8ed91e1da22be..1aa43994a3cdc 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2552,6 +2552,15 @@ static int pl011_console_setup(struct console *co, char *options)
>  	return uart_set_options(&uap->port, co, baud, parity, bits, flow);
>  }
>  
> +static int pl011_console_exit(struct console *co)
> +{
> +	struct uart_amba_port *uap = amba_ports[co->index];
> +

[Severity: High]
This is a pre-existing issue, but does uap need a NULL check here to
prevent a kernel panic on error paths?

If uart_add_one_port() fails internally (e.g., an allocation failure in
serial_core_add_one_port() returning -ENOMEM), it returns an error but
crucially fails to unregister the console that was already registered
earlier in uart_configure_port().

The caller sees the error and clears the pointer:

drivers/tty/serial/amba-pl011.c:pl011_register_port() {
    ...
    ret = uart_add_one_port(&amba_reg, &uap->port);
    if (ret)
        pl011_unregister_port(uap);
    ...
}

Because pl011_unregister_port() clears amba_ports[co->index] to NULL, but
the console remains active in the system's console list, will
unconditionally dereferencing uap here (and in pl011_console_write_atomic)
cause a crash when invoked?

> +	clk_unprepare(uap->clk);
> +
> +	return 0;
> +}
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719063502.18852-1-kmehltretter@gmail.com?part=1

Re: [PATCH 1/2] serial: amba-pl011: unprepare console clock on unregister

[Karl Mehltretter]

On Sun, Jul 19, 2026 at 07:04:54AM +0100, sashiko-bot@kernel.org wrote:
> This is a pre-existing issue, but does uap need a NULL check here to
> prevent a kernel panic on error paths?
> 
> If uart_add_one_port() fails internally (e.g., an allocation failure in
> serial_core_add_one_port() returning -ENOMEM), it returns an error but
> crucially fails to unregister the console that was already registered
> earlier in uart_configure_port().
> 
> The caller sees the error and clears the pointer:
> 
> drivers/tty/serial/amba-pl011.c:pl011_register_port() {
>     ...
>     ret = uart_add_one_port(&amba_reg, &uap->port);
>     if (ret)
>         pl011_unregister_port(uap);

Good catch in a rare error path.  A NULL check alone is not enough
because other callbacks use the same pointer.

The underlying issue is that serial core can leave the console registered
after uart_add_one_port() fails. I will investigate that separately.

Karl

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

[Karl Mehltretter]

pl011_console_write_atomic() runs from nbcon atomic context, where
sleeping is not allowed. It calls clk_enable(), which takes the
common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock:
clk_enable_lock() first tries spin_trylock_irqsave(), but on contention
falls back to spin_lock_irqsave(), so an atomic-context printk on an RT
kernel with a clk-backed pl011 can trip:

  BUG: sleeping function called from invalid context at spinlock_rt.c:48
    __might_resched from rt_spin_lock
    rt_spin_lock from clk_enable_lock
    clk_enable_lock from clk_enable
    clk_enable from pl011_console_write_atomic
    ... from vprintk_emit

This was found and reproduced on 32-bit ARM with PREEMPT_RT. In
addition, write_atomic() may be invoked from NMI context and is
documented to avoid locking. Since clk_enable() acquires the
common-clock enable_lock, removing it from the callback also avoids a
potentially unsafe NMI lock acquisition.

An nbcon atomic-capable console must be printable from any context, so
the clock cannot be gated between writes. Enable the clock while the
console is registered: use clk_prepare_enable() in
pl011_console_setup(), release it via clk_disable_unprepare() in the
console .exit() callback, and drop the per-write
clk_enable()/clk_disable() pairs from write_atomic() and
write_thread().

Keeping UARTCLK enabled may increase idle power on platforms where it
would otherwise be gated between console writes.

Fixes: 2eb2608618ce ("serial: amba-pl011: Implement nbcon console")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
The PREEMPT_RT splat above was reproduced on 32-bit ARM (versatilepb,
ARM926EJ-S / ARMv5TE), Linux 7.2.0-rc3 based, CONFIG_PREEMPT_RT=y
CONFIG_HZ=1000, by driving an atomic-context printk; with this patch the
clk_enable() -> rt_spin_lock() splat is gone.

Tested on QEMU raspi (bcm2835, gateable CPRMAN UART clock) with the full
series applied: recycling the console via /sys/class/tty/ttyAMA0/console
keeps both prepare_count and enable_count balanced (2/2 across six
cycles), and console output resumes after each re-registration.
Suspend/resume was not exercised (no platform suspend under the QEMU
model).

 drivers/tty/serial/amba-pl011.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 1aa43994a3cd..4facd1b350d5 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2523,7 +2523,11 @@ static int pl011_console_setup(struct console *co, char *options)
 	/* Allow pins to be muxed in and configured */
 	pinctrl_pm_select_default_state(uap->port.dev);
 
-	ret = clk_prepare(uap->clk);
+	/*
+	 * Keep the clock enabled while registered because write_atomic() may
+	 * run in NMI context and must not acquire the clock framework lock.
+	 */
+	ret = clk_prepare_enable(uap->clk);
 	if (ret)
 		return ret;
 
@@ -2556,7 +2560,7 @@ static int pl011_console_exit(struct console *co)
 {
 	struct uart_amba_port *uap = amba_ports[co->index];
 
-	clk_unprepare(uap->clk);
+	clk_disable_unprepare(uap->clk);
 
 	return 0;
 }
@@ -2630,8 +2634,6 @@ pl011_console_write_atomic(struct console *co, struct nbcon_write_context *wctxt
 	if (!nbcon_enter_unsafe(wctxt))
 		return;
 
-	clk_enable(uap->clk);
-
 	if (!uap->vendor->always_enabled) {
 		old_cr = pl011_read(uap, REG_CR);
 		pl011_write((old_cr & ~UART011_CR_CTSEN) | (UART01x_CR_UARTEN | UART011_CR_TXE),
@@ -2648,8 +2650,6 @@ pl011_console_write_atomic(struct console *co, struct nbcon_write_context *wctxt
 	if (!uap->vendor->always_enabled)
 		pl011_write(old_cr, uap, REG_CR);
 
-	clk_disable(uap->clk);
-
 	nbcon_exit_unsafe(wctxt);
 }
 
@@ -2662,8 +2662,6 @@ pl011_console_write_thread(struct console *co, struct nbcon_write_context *wctxt
 	if (!nbcon_enter_unsafe(wctxt))
 		return;
 
-	clk_enable(uap->clk);
-
 	if (!uap->vendor->always_enabled) {
 		old_cr = pl011_read(uap, REG_CR);
 		pl011_write((old_cr & ~UART011_CR_CTSEN) | (UART01x_CR_UARTEN | UART011_CR_TXE),
@@ -2692,8 +2690,6 @@ pl011_console_write_thread(struct console *co, struct nbcon_write_context *wctxt
 	if (!uap->vendor->always_enabled)
 		pl011_write(old_cr, uap, REG_CR);
 
-	clk_disable(uap->clk);
-
 	nbcon_exit_unsafe(wctxt);
 }
 
-- 
2.53.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The UART clock is kept unconditionally enabled during system suspend, potentially preventing deep system sleep.
--

--- Patch [2]: [PATCH 2/2] serial: amba-pl011: keep console clock enabled for atomic writes ---
commit d187007d951bc1373a13bbdbd4ba5d6db47490d1
Author: Karl Mehltretter <kmehltretter@gmail.com>

serial: amba-pl011: keep console clock enabled for atomic writes

This commit fixes a sleeping-in-atomic bug under PREEMPT_RT by keeping the
console clock enabled while the console is registered. It moves the clock
enable from the atomic write path to console setup and exit.

> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 1aa43994a3cdc..4facd1b350d5d 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2523,7 +2523,11 @@ static int pl011_console_setup(struct console *co, char *options)
>  	/* Allow pins to be muxed in and configured */
>  	pinctrl_pm_select_default_state(uap->port.dev);
>  
> -	ret = clk_prepare(uap->clk);
> +	/*
> +	 * Keep the clock enabled while registered because write_atomic() may
> +	 * run in NMI context and must not acquire the clock framework lock.
> +	 */
> +	ret = clk_prepare_enable(uap->clk);

[Severity: High]
Will this keep the UART clock unconditionally enabled during system suspend?

Because the persistent clock reference is acquired here during console
registration and only dropped on console exit in pl011_console_exit(), the
reference remains active.

During system suspend, pl011_suspend() delegates to uart_suspend_port() but
fails to drop this console's persistent clock enable reference. This might
prevent the SoC from turning off the clock tree or parent PLLs, preventing
deep system sleep.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719063502.18852-1-kmehltretter@gmail.com?part=2

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

[Sebastian Andrzej Siewior]

On 2026-07-19 06:52:14 [+0000], sashiko-bot@kernel.org wrote:
> > diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> > index 1aa43994a3cdc..4facd1b350d5d 100644
> > --- a/drivers/tty/serial/amba-pl011.c
> > +++ b/drivers/tty/serial/amba-pl011.c
> > @@ -2523,7 +2523,11 @@ static int pl011_console_setup(struct console *co, char *options)
> >  	/* Allow pins to be muxed in and configured */
> >  	pinctrl_pm_select_default_state(uap->port.dev);
> >  
> > -	ret = clk_prepare(uap->clk);
> > +	/*
> > +	 * Keep the clock enabled while registered because write_atomic() may
> > +	 * run in NMI context and must not acquire the clock framework lock.
> > +	 */
> > +	ret = clk_prepare_enable(uap->clk);
> 
> [Severity: High]
> Will this keep the UART clock unconditionally enabled during system suspend?
> 
> Because the persistent clock reference is acquired here during console
> registration and only dropped on console exit in pl011_console_exit(), the
> reference remains active.
> 
> During system suspend, pl011_suspend() delegates to uart_suspend_port() but
> fails to drop this console's persistent clock enable reference. This might
> prevent the SoC from turning off the clock tree or parent PLLs, preventing
> deep system sleep.

The comment somehow makes sense. What is the general advice here? If we
drop the clock during suspend and acquire it again during resume we need
to keep track and ignore all prints in between. Is the pritnk core
taking care of this? There is also this no_console_suspend argument…

Sebastian

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

[John Ogness]

On 2026-07-20, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> On 2026-07-19 06:52:14 [+0000], sashiko-bot@kernel.org wrote:
>> > diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
>> > index 1aa43994a3cdc..4facd1b350d5d 100644
>> > --- a/drivers/tty/serial/amba-pl011.c
>> > +++ b/drivers/tty/serial/amba-pl011.c
>> > @@ -2523,7 +2523,11 @@ static int pl011_console_setup(struct console *co, char *options)
>> >  	/* Allow pins to be muxed in and configured */
>> >  	pinctrl_pm_select_default_state(uap->port.dev);
>> >  
>> > -	ret = clk_prepare(uap->clk);
>> > +	/*
>> > +	 * Keep the clock enabled while registered because write_atomic() may
>> > +	 * run in NMI context and must not acquire the clock framework lock.
>> > +	 */
>> > +	ret = clk_prepare_enable(uap->clk);
>> 
>> [Severity: High]
>> Will this keep the UART clock unconditionally enabled during system suspend?
>> 
>> Because the persistent clock reference is acquired here during console
>> registration and only dropped on console exit in pl011_console_exit(), the
>> reference remains active.
>> 
>> During system suspend, pl011_suspend() delegates to uart_suspend_port() but
>> fails to drop this console's persistent clock enable reference. This might
>> prevent the SoC from turning off the clock tree or parent PLLs, preventing
>> deep system sleep.
>
> The comment somehow makes sense. What is the general advice here? If we
> drop the clock during suspend and acquire it again during resume we need
> to keep track and ignore all prints in between. Is the printk core
> taking care of this?

This is what the suspend/resume pm callbacks are for. In this case, it
is pl011_suspend() and pl011_resume().

> There is also this no_console_suspend argument…

Yes, the callbacks need to check @console_suspend_enabled. If false, the
clocks obviously must not be disabled.

John Ogness

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

[Sebastian Andrzej Siewior]

On 2026-07-20 10:19:58 [+0206], John Ogness wrote:
> This is what the suspend/resume pm callbacks are for. In this case, it
> is pl011_suspend() and pl011_resume().

Perfect so everything is in place except for these two.

> > There is also this no_console_suspend argument…
> 
> Yes, the callbacks need to check @console_suspend_enabled. If false, the
> clocks obviously must not be disabled.

good.

> John Ogness

Sebastian

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

[Karl Mehltretter]

On Mon, Jul 20, 2026 at 10:26:40AM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-07-20 10:19:58 [+0206], John Ogness wrote:
> > This is what the suspend/resume pm callbacks are for. In this case, it
> > is pl011_suspend() and pl011_resume().
> 
> Perfect so everything is in place except for these two.
> 
> > > There is also this no_console_suspend argument…
> > 
> > Yes, the callbacks need to check @console_suspend_enabled. If false, the
> > clocks obviously must not be disabled.
> 
> good.
> 

All right, I will send a v2 patch for this.

My testing is limited to QEMU, so I cannot test the power impact or
behaviour of real SoCs.

Karl

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

[Petr Mladek]

Adding ARM mailing list into Cc.

On Sun 2026-07-19 08:35:02, Karl Mehltretter wrote:
> pl011_console_write_atomic() runs from nbcon atomic context, where
> sleeping is not allowed. It calls clk_enable(), which takes the
> common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock:
> clk_enable_lock() first tries spin_trylock_irqsave(), but on contention
> falls back to spin_lock_irqsave(), so an atomic-context printk on an RT
> kernel with a clk-backed pl011 can trip:
> 
>   BUG: sleeping function called from invalid context at spinlock_rt.c:48
>     __might_resched from rt_spin_lock
>     rt_spin_lock from clk_enable_lock
>     clk_enable_lock from clk_enable
>     clk_enable from pl011_console_write_atomic
>     ... from vprintk_emit
> 
> This was found and reproduced on 32-bit ARM with PREEMPT_RT. In
> addition, write_atomic() may be invoked from NMI context and is
> documented to avoid locking. Since clk_enable() acquires the
> common-clock enable_lock, removing it from the callback also avoids a
> potentially unsafe NMI lock acquisition.
> 
> An nbcon atomic-capable console must be printable from any context, so
> the clock cannot be gated between writes. Enable the clock while the
> console is registered: use clk_prepare_enable() in
> pl011_console_setup(), release it via clk_disable_unprepare() in the
> console .exit() callback, and drop the per-write
> clk_enable()/clk_disable() pairs from write_atomic() and
> write_thread().
> 
> Keeping UARTCLK enabled may increase idle power on platforms where it
> would otherwise be gated between console writes.

Just to be sure. Is this acceptable, please?

I have no idea what is the real life effect. It might be negligible.
Or maybe it does not effect production systems at all because
they do not have the serial console enabled.

I just wonder if it might considerably increase the battery usage
of some devices, e.g. watches or earbuds, just because of the possibility
to write emergency messages via the serial console.

Best Regards,
Petr

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

[Sebastian Andrzej Siewior]

On 2026-07-20 13:45:58 [+0200], Petr Mladek wrote:
> Just to be sure. Is this acceptable, please?

As John said, the pm hooks should be updated.

-> https://lore.kernel.org/all/8733xeaxix.fsf@jogness.linutronix.de/

> Best Regards,
> Petr

Sebastian