[PATCH v2] Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration"

[PATCH v2] Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration"

[Fushuai Wang]

From: Fushuai Wang <wangfushuai@baidu.com>

This reverts commit d338ab1d90603f875c4f7ed223406535378173a5.

uart_console() only indicates that the port is selected as the console.
It does not mean that the console has already been registered or has
printed the buffered messages.

On platforms where an initial 8250 port is replaced when the real UART
device is registered, clearing CON_PRINTBUFFER causes the console to
start at the end of the printk ring buffer. Without earlycon, all
messages logged before UART registration are therefore lost.

Reported-by: Mark Brown <broonie@kernel.org>
Reported-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Link: https://lore.kernel.org/all/20260522101042.21976-1-fushuai.wang@linux.dev/
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
---

The reverted commit is currently in tty/tty-next and tty/tty-testing,
and has appeared in linux-next since next-20260717.

v1->v2: Expand the commit message with detailed explanation of the regression.

 drivers/tty/serial/8250/8250_core.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index c0e8a4efbdcc..f49862d90eeb 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -720,12 +720,8 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
 	/* Preserve specified console flow control. */
 	cons_flow = uart_cons_flow_enabled(&uart->port);
 
-	if (uart->port.dev) {
-		if (uart_console(&uart->port))
-			uart->port.cons->flags &= ~CON_PRINTBUFFER;
-
+	if (uart->port.dev)
 		uart_remove_one_port(&serial8250_reg, &uart->port);
-	}
 
 	uart->port.ctrl_id	= up->port.ctrl_id;
 	uart->port.port_id	= up->port.port_id;
-- 
2.36.1

Re: [PATCH v2] Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration"

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Fri, Jul 24, 2026 at 05:31:51PM +0800, Fushuai Wang wrote:
> From: Fushuai Wang <wangfushuai@baidu.com>
> 
> This reverts commit d338ab1d90603f875c4f7ed223406535378173a5.
> 
> uart_console() only indicates that the port is selected as the console.
> It does not mean that the console has already been registered or has
> printed the buffered messages.

The multi-system boot regression this fixes is still present in -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2] Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration"

[Fushuai Wang]

> > From: Fushuai Wang <wangfushuai@baidu.com>
> > 
> > This reverts commit d338ab1d90603f875c4f7ed223406535378173a5.
> > 
> > uart_console() only indicates that the port is selected as the console.
> > It does not mean that the console has already been registered or has
> > printed the buffered messages.
> 
> The multi-system boot regression this fixes is still present in -next.

Hi, Greg

Just a ping.

Mark has confirmed that the regression is still present in -next.
Could you please take a look and consider applying it to tty/tty-testing 
and tty/tty-next?

-- 
Regards,
Fushuai

Re: [PATCH v2] Revert "serial: 8250: Clear CON_PRINTBUFFER on port re-registration"

[Greg KH]

On Wed, Jul 29, 2026 at 07:26:05PM +0800, Fushuai Wang wrote:
> > > From: Fushuai Wang <wangfushuai@baidu.com>
> > > 
> > > This reverts commit d338ab1d90603f875c4f7ed223406535378173a5.
> > > 
> > > uart_console() only indicates that the port is selected as the console.
> > > It does not mean that the console has already been registered or has
> > > printed the buffered messages.
> > 
> > The multi-system boot regression this fixes is still present in -next.
> 
> Hi, Greg
> 
> Just a ping.
> 
> Mark has confirmed that the regression is still present in -next.
> Could you please take a look and consider applying it to tty/tty-testing 
> and tty/tty-next?

Will do, working on my patch queue right now...