[PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Fushuai Wang <fushuai.wang@linux.dev>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2041 bytes --]

> > On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:
>
> > Seems like this patch was added in next-20261717.
>
> 0717
>
> > I'm noticing that this patch is causing no serial output to be visible
> > on riscv boards till the uart device is registered. Normally while
> > booting, we expect for all the prints made before this to be
> > buffered and appear post serial device initialization.
> >
> > => booti 0x11000000 0x21000000:${initrd_size} 0x31000000
> > Moving Image from 0x11000000 to 0x200000, end=1ca6000
> > [ 161.301] ## Flattened Device Tree blob at 31000000
> > [ 161.302]    Booting using the fdt blob at 0x31000000
> > [ 161.307]    Loading Ramdisk to 7653e000, end 7dd81853 ... OK
> > [ 161.366]    Loading Device Tree to 0000000076532000, end 000000007653d25d ... OK
> >
> > Starting kernel ...
> >
> > [    0.235159] printk: legacy console [ttyS0] enabled
> > [    0.238787] /soc/i2c@d401d800/pmic@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
> >
> > Most devs who are debugging might be booting with the earlycon boot
> > parameter. If earlycon is present, serial output is present, but
> > with earlycon missing (which is what most distros use), I don't get
> > any serial output till this point.
>
> Perhaps it's inconvenient. Logically I support using earlycon (I have
> noticed a few times in the past double printing of the kernel buffer
> to the serial console). So I tend more towards that this patch
> actually gives a better experience. However, I haven't given any tag
> to it, nor do I object to any improvements or reverting to the old
> behaviour — your inconvenience will become mine :-)
>
> Just my 2c.
>
> -- 
> With Best Regards,
> Andy Shevchenko

Hi, Andy and Anirudh

Thanks for the report. I only tested this on x86 and don't have a
RISC-V environment.

I think this patch should be reverted in -next. Since I haven't done
this before, could you let me know the proper way to handle this?
I'll also explore a better approach later.

-- 
Regards,
Fushuai