[PATCH tty] serial: 8250: Ignore flow control on suspend/resume with no_console_suspend

[PATCH tty] serial: 8250: Ignore flow control on suspend/resume with no_console_suspend

[John Ogness]

If no_console_suspend is specified, on suspend the 8250 console driver
uses a scratch register (UART_SCR) to store a special canary value. This
is used during the resume path to identify a printk() call before the
driver's own ->resume() callback. In this case,
serial8250_console_restore() is called to quickly re-init the 8250 for
console printing.

See commit 4516d50aabed ("serial: 8250: Use canary to restart console after
suspend") for the original motivation.

Unfortunately, this canary workaround does not work in all cases (such as
suspend to mem) because the scratch register will not reset. This has not
been a real issue until now because it could simply lead to some garbage
characters upon resume. However, with the introduction of console flow
control it becomes a real problem because a failed suspend/resume detection
when flow control is enabled leads to all characters hitting the flow
control timeout.

Workaround this issue by temporarily ignoring console flow control when
the debug canary suspend/resume detection is active.

Fixes: 5e6dfb87b191 ("serial: 8250: Add support for console flow control")
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
 This should be included in the 7.2 release to avoid fallout
 from the 8250 console flow control support added for 7.2.

 drivers/tty/serial/8250/8250_port.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 630deb7dd3449..38de6398e756c 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2000,8 +2000,14 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
 
 	tx_ready = wait_for_lsr(up, bits);
 
-	/* Wait up to 1s for flow control if necessary */
-	if (uart_console_hwflow_active(&up->port)) {
+	/*
+	 * Wait up to 1s for flow control if necessary.
+	 * When 'no_console_suspend' is active (in the window between
+	 * suspend() and resume()), flow control is temporarily ignored
+	 * because the canary workaround is not reliable in all situations,
+	 * leading to flow control timeouts for every character.
+	 */
+	if (uart_console_hwflow_active(&up->port) && !up->canary) {
 		for (tmout = 1000000; tmout; tmout--) {
 			unsigned int msr = serial_in(up, UART_MSR);
 			up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;

base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
-- 
2.47.3

Re: [PATCH tty] serial: 8250: Ignore flow control on suspend/resume with no_console_suspend

[John Ogness]

On 2026-07-07, sashiko.dev wrote:
>> -	/* Wait up to 1s for flow control if necessary */
>> -	if (uart_console_hwflow_active(&up->port)) {
>> +	/*
>> +	 * Wait up to 1s for flow control if necessary.
>> +	 * When 'no_console_suspend' is active (in the window between
>> +	 * suspend() and resume()), flow control is temporarily ignored
>> +	 * because the canary workaround is not reliable in all situations,
>> +	 * leading to flow control timeouts for every character.
>> +	 */
>> +	if (uart_console_hwflow_active(&up->port) && !up->canary) {
>
> This isn't a bug introduced by this patch, but does this incomplete
> fix still allow flow control timeouts if the UART loses power during
> suspend?

Yes, and this is fine. More below...

> Looking at serial8250_console_write(), if power is lost, the canary is
> successfully matched, the UART is restored, and the canary is cleared
> to 0:
>
> serial8250_console_write() {
>     ...
>     if (up->canary && (up->canary != serial_port_in(port, UART_SCR))) {
>         serial8250_console_restore(up);
>         up->canary = 0;
>     }
>     ...
> }
>
> Since this happens before the actual characters are printed, won't
> subsequent calls to wait_for_xmitr() see !up->canary as true and
> re-enable the flow control wait loop for each character?

Yes, and that is correct behavior. When serial8250_console_restore() is
called (right before clearing @canary), hardware flow control is
correctly re-configured, thus hardware flow control will work correctly
and it is fine for wait_for_xmitr() to poll.

John