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>
Link: https://patch.msgid.link/20260707141032.5074-1-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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;