[PATCH v1 0/3] serial: Support driver-selected TTY wakeup defaults

[PATCH v1 0/3] serial: Support driver-selected TTY wakeup defaults

[Stefano Radaelli]

The initial goal was to enable TTY wakeup by default on NXP LPUART ports
marked with wakeup-source, without requiring a userspace write. Instead
of keeping this entirely within fsl_lpuart, this series introduces a
common serial core mechanism that other UART drivers can also adopt.

The new tty_wakeup_default field in struct uart_port lets a driver request
wakeup to be enabled when its TTY device is registered. Each driver
decides whether to use it. This series adds wakeup-source to the LPUART
binding and makes fsl_lpuart the first user, setting the field from that
property. Other drivers retain their existing behavior, userspace can
still change power/wakeup, and serdev wakeup policy is unchanged.

Tested on a Variscite VAR-SOM-MX93 with a Symphony carrier board using
LPUART1 (ttyLP0) as the console: with wakeup-source present, power/wakeup
was enabled after boot, and the board resumed from deep suspend when
Enter was pressed on the serial console.

Stefano Radaelli (3):
  dt-bindings: serial: fsl-lpuart: Allow wakeup-source
  serial: core: Allow drivers to enable TTY wakeup at registration
  serial: fsl_lpuart: Enable TTY wakeup for wakeup-source ports

 Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 ++
 drivers/tty/serial/fsl_lpuart.c                          | 1 +
 drivers/tty/serial/serial_core.c                         | 8 ++++++++
 include/linux/serial_core.h                              | 1 +
 4 files changed, 12 insertions(+)


base-commit: 2637bdec0535a2044cd830eba9a79363651d9043
-- 
2.47.3

[PATCH v1 1/3] dt-bindings: serial: fsl-lpuart: Allow wakeup-source

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

LPUART supports waking the system on receive activity. Allow the
wakeup-source property to describe ports intended for system wakeup.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
index c42261b5a80a..5c1237294a62 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
@@ -74,6 +74,8 @@ properties:
   power-domains:
     maxItems: 1
 
+  wakeup-source: true
+
 required:
   - compatible
   - reg
-- 
2.47.3

[PATCH v1 2/3] serial: core: Allow drivers to enable TTY wakeup at registration

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

The serial core marks registered TTY devices as wakeup capable but leaves
wakeup disabled. Drivers whose suspend path checks the TTY wakeup policy
cannot enable that policy by initializing wakeup on the physical parent.

Add tty_wakeup_default to struct uart_port so a driver can request that
the core enable wakeup when registering its TTY device. The field only
sets the initial policy; userspace can still change power/wakeup.

Apply the setting only to the matching TTY device, leaving serdev wakeup
policy unchanged. Drivers that do not set the field retain the existing
default. Warn if enabling wakeup fails without preventing port use.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 drivers/tty/serial/serial_core.c | 8 ++++++++
 include/linux/serial_core.h      | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c0deec0e6af4..aa18d0820060 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3121,9 +3121,11 @@ static const struct attribute_group tty_dev_attr_group = {
  */
 static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *uport)
 {
+	struct uart_match match = { uport, drv };
 	struct uart_state *state;
 	struct tty_port *port;
 	struct device *tty_dev;
+	int ret;
 
 	if (uport->line >= drv->nr)
 		return -EINVAL;
@@ -3196,6 +3198,12 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u
 			uport->tty_groups);
 	if (!IS_ERR(tty_dev)) {
 		device_set_wakeup_capable(tty_dev, 1);
+		/* Serdev clients manage their own wakeup policy. */
+		if (uport->tty_wakeup_default && serial_match_port(tty_dev, &match)) {
+			ret = device_set_wakeup_enable(tty_dev, true);
+			if (ret)
+				dev_warn(tty_dev, "Failed to enable wakeup: %d\n", ret);
+		}
 	} else {
 		uport->flags |= UPF_DEAD;
 		dev_err(uport->dev, "Cannot register tty device on line %u\n",
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 4eeb8253752a..d5a0666d782f 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -573,6 +573,7 @@ struct uart_port {
 
 	bool			hw_stopped;		/* sw-assisted CTS flow state */
 	bool			cons_flow;		/* user specified console flow control */
+	bool			tty_wakeup_default;	/* Enable TTY wakeup at registration */
 	unsigned int		mctrl;			/* current modem ctrl settings */
 	unsigned int		frame_time;		/* frame timing in ns */
 	unsigned int		type;			/* port type */
-- 
2.47.3

[PATCH v1 3/3] serial: fsl_lpuart: Enable TTY wakeup for wakeup-source ports

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

LPUART checks the TTY wakeup policy when preparing a port for system
suspend, but does not currently use the wakeup-source DT property.
Consequently, userspace must enable TTY wakeup even for ports marked as
wakeup sources.

Set tty_wakeup_default from wakeup-source before registering the port.
For TTY ports with the property, the serial core then enables wakeup at
registration. Ports without it keep the existing default, and userspace
can still disable wakeup through power/wakeup. The port must still be
open and initialized for receive activity to wake the system.

Tested on a Variscite VAR-SOM-MX93 with a Symphony carrier board using
LPUART1 (ttyLP0) as the console. With wakeup-source present, power/wakeup
was enabled after boot without a userspace write. After requesting deep
suspend, the board stayed suspended until Enter was pressed on the serial
console, then resumed.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 drivers/tty/serial/fsl_lpuart.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index c8575c965203..35397152a39b 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2905,6 +2905,7 @@ static int lpuart_probe(struct platform_device *pdev)
 		sport->port.ops = &lpuart_pops;
 	sport->port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_FSL_LPUART_CONSOLE);
 	sport->port.flags = UPF_BOOT_AUTOCONF;
+	sport->port.tty_wakeup_default = of_property_read_bool(np, "wakeup-source");
 
 	if (lpuart_is_32(sport))
 		sport->port.rs485_config = lpuart32_config_rs485;
-- 
2.47.3

Re: [PATCH v1 1/3] dt-bindings: serial: fsl-lpuart: Allow wakeup-source

[sashiko-bot]

> From: Stefano Radaelli <stefano.r@variscite.com>
> 
> LPUART supports waking the system on receive activity. Allow the
> wakeup-source property to describe ports intended for system wakeup.
> 
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793719239.git.stefano.r@variscite.com?part=1

Re: [PATCH v1 2/3] serial: core: Allow drivers to enable TTY wakeup at registration

[sashiko-bot]

> From: Stefano Radaelli <stefano.r@variscite.com>
> 
> The serial core marks registered TTY devices as wakeup capable but leaves
> wakeup disabled. Drivers whose suspend path checks the TTY wakeup policy
> cannot enable that policy by initializing wakeup on the physical parent.
> 
> Add tty_wakeup_default to struct uart_port so a driver can request that
> the core enable wakeup when registering its TTY device. The field only
> sets the initial policy; userspace can still change power/wakeup.
> 
> Apply the setting only to the matching TTY device, leaving serdev wakeup
> policy unchanged. Drivers that do not set the field retain the existing
> default. Warn if enabling wakeup fails without preventing port use.
> 
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793719239.git.stefano.r@variscite.com?part=2

Re: [PATCH v1 3/3] serial: fsl_lpuart: Enable TTY wakeup for wakeup-source ports

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] serial: fsl_lpuart: suspend state mismatch in lpuart_uport_is_active()
--

commit 5f417acc28861452465313313b5ef22d373f3ae3
Author: Stefano Radaelli <stefano.r@variscite.com>

serial: fsl_lpuart: Enable TTY wakeup for wakeup-source ports

This commit sets tty_wakeup_default in lpuart_probe() from the wakeup-source
device tree property so the serial core enables TTY wakeup at registration
time.

> diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
> index c8575c9652035..35397152a39b3 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -2905,6 +2905,7 @@ static int lpuart_probe(struct platform_device *pdev)
>  		sport->port.ops = &lpuart_pops;
>  	sport->port.has_sysrq = IS_ENABLED(CONFIG_SERIAL_FSL_LPUART_CONSOLE);
>  	sport->port.flags = UPF_BOOT_AUTOCONF;
> +	sport->port.tty_wakeup_default = of_property_read_bool(np, "wakeup-source");

[Severity: High]
Does enabling tty_wakeup_default at registration time cause a suspend and
resume state mismatch between the serial core and lpuart_uport_is_active()
when the TTY device is not open in userspace?

With tty_wakeup_default set, serial_core_add_one_port() enables wakeup on
tty_dev during probe before any process opens the port (when port->tty is
NULL and tty_port_initialized(port) is false).

If the system suspends while the port is closed, lpuart_suspend() calls
uart_suspend_port(), which checks device_may_wakeup(tty_dev) without checking
tty_port_initialized(port):

drivers/tty/serial/serial_core.c:uart_suspend_port() {
	...
	tty_dev = tty_port_find_device(port);
	if (tty_dev && device_may_wakeup(tty_dev)) {
		enable_irq_wake(uport->irq);
		put_device(tty_dev);
		return 0;
	}
	put_device(tty_dev);
	...
}

Because uart_suspend_port() returns early here, it leaves uport->suspended as
0 and skips console_suspend(uport->cons) as well as uart_change_pm(state,
UART_PM_STATE_OFF).

However, lpuart_suspend() then checks lpuart_uport_is_active(sport), which
requires both a non-NULL port->tty and tty_port_initialized(port):

drivers/tty/serial/fsl_lpuart.c:lpuart_uport_is_active() {
	...
	tty = tty_port_tty_get(port);
	if (tty) {
		tty_dev = tty->dev;
		may_wake = tty_dev && device_may_wakeup(tty_dev);
		tty_kref_put(tty);
	}

	if ((tty_port_initialized(port) && may_wake) ||
	    (!console_suspend_enabled && uart_console(&sport->port)))
		return true;

	return false;
}

When the port is not open in userspace and console_suspend_enabled is true,
lpuart_uport_is_active(sport) returns false, causing lpuart_suspend() to take
the else-if branch and disable ipg_clk and baud_clk while the console is
still active and unsuspended:

drivers/tty/serial/fsl_lpuart.c:lpuart_suspend() {
	...
	} else if (pm_runtime_active(sport->port.dev)) {
		lpuart_disable_clks(sport);
		pm_runtime_disable(sport->port.dev);
		pm_runtime_set_suspended(sport->port.dev);
	}
}

Wouldn't any printk() during suspend or early resume then call
lpuart32_console_write() or lpuart_console_write() while the LPUART clocks
are disabled, triggering an unclocked MMIO access (bus hang or synchronous
external abort)?

Similarly, on resume, lpuart_resume() skips lpuart32_hw_setup(),
lpuart_hw_setup(), and lpuart_console_fixup() because
lpuart_uport_is_active(sport) is false, while uart_resume_port() also returns
early without restoring console termios or calling console_resume() because
!uport->suspended && device_may_wakeup(tty_dev) is true:

drivers/tty/serial/serial_core.c:uart_resume_port() {
	...
	if (!uport->suspended && device_may_wakeup(tty_dev)) {
		if (irqd_is_wakeup_set(irq_get_irq_data((uport->irq))))
			disable_irq_wake(uport->irq);
		put_device(tty_dev);
		return 0;
	}
	...
}

If the LPUART loses power during deep sleep while the console TTY is closed,
doesn't this leave the console hardware uninitialized after resume?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793719239.git.stefano.r@variscite.com?part=3

Re: [PATCH v1 3/3] serial: fsl_lpuart: Enable TTY wakeup for wakeup-source ports

[Stefano Radaelli]

On Tue, Nov 03, 2026 at 04:07:25PM +0000, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Does enabling tty_wakeup_default at registration time cause a suspend and
> resume state mismatch between the serial core and lpuart_uport_is_active()
> when the TTY device is not open in userspace?
> 
> With tty_wakeup_default set, serial_core_add_one_port() enables wakeup on
> tty_dev during probe before any process opens the port (when port->tty is
> NULL and tty_port_initialized(port) is false).
> 
> If the system suspends while the port is closed, lpuart_suspend() calls
> uart_suspend_port(), which checks device_may_wakeup(tty_dev) without checking
> tty_port_initialized(port):
> 
> drivers/tty/serial/serial_core.c:uart_suspend_port() {
> 	...
> 	tty_dev = tty_port_find_device(port);
> 	if (tty_dev && device_may_wakeup(tty_dev)) {
> 		enable_irq_wake(uport->irq);
> 		put_device(tty_dev);
> 		return 0;
> 	}
> 	put_device(tty_dev);
> 	...
> }
> 
> Because uart_suspend_port() returns early here, it leaves uport->suspended as
> 0 and skips console_suspend(uport->cons) as well as uart_change_pm(state,
> UART_PM_STATE_OFF).
> 
> However, lpuart_suspend() then checks lpuart_uport_is_active(sport), which
> requires both a non-NULL port->tty and tty_port_initialized(port):
> 
> drivers/tty/serial/fsl_lpuart.c:lpuart_uport_is_active() {
> 	...
> 	tty = tty_port_tty_get(port);
> 	if (tty) {
> 		tty_dev = tty->dev;
> 		may_wake = tty_dev && device_may_wakeup(tty_dev);
> 		tty_kref_put(tty);
> 	}
> 
> 	if ((tty_port_initialized(port) && may_wake) ||
> 	    (!console_suspend_enabled && uart_console(&sport->port)))
> 		return true;
> 
> 	return false;
> }
> 
> When the port is not open in userspace and console_suspend_enabled is true,
> lpuart_uport_is_active(sport) returns false, causing lpuart_suspend() to take
> the else-if branch and disable ipg_clk and baud_clk while the console is
> still active and unsuspended:
> 
> drivers/tty/serial/fsl_lpuart.c:lpuart_suspend() {
> 	...
> 	} else if (pm_runtime_active(sport->port.dev)) {
> 		lpuart_disable_clks(sport);
> 		pm_runtime_disable(sport->port.dev);
> 		pm_runtime_set_suspended(sport->port.dev);
> 	}
> }
> 
> Wouldn't any printk() during suspend or early resume then call
> lpuart32_console_write() or lpuart_console_write() while the LPUART clocks
> are disabled, triggering an unclocked MMIO access (bus hang or synchronous
> external abort)?
> 
> Similarly, on resume, lpuart_resume() skips lpuart32_hw_setup(),
> lpuart_hw_setup(), and lpuart_console_fixup() because
> lpuart_uport_is_active(sport) is false, while uart_resume_port() also returns
> early without restoring console termios or calling console_resume() because
> !uport->suspended && device_may_wakeup(tty_dev) is true:
> 
> drivers/tty/serial/serial_core.c:uart_resume_port() {
> 	...
> 	if (!uport->suspended && device_may_wakeup(tty_dev)) {
> 		if (irqd_is_wakeup_set(irq_get_irq_data((uport->irq))))
> 			disable_irq_wake(uport->irq);
> 		put_device(tty_dev);
> 		return 0;
> 	}
> 	...
> }
> 
> If the LPUART loses power during deep sleep while the console TTY is closed,
> doesn't this leave the console hardware uninitialized after resume?
> 

The suspend/resume mismatch described here predates this series and is
already reachable by enabling the TTY device's power/wakeup attribute
from userspace with the port closed.
This series changes the initial wakeup policy, it does not introduce the
mismatch.
The underlying suspend/resume handling should be discussed and
addressed separately, rather than attributed to this patch.

> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793719239.git.stefano.r@variscite.com?part=3