On Wed, 16 Mar 2022, Wander Lairson Costa wrote: > The serial driver set the value of uart_8250_port.fcr in the function > serial8250_config_port, but only writes the value to the controller > register later in the initalization code. > > That opens a small window in which is not safe to use the fifo for > console write. > > Make sure the port is initialized correctly before reading the FCR > cached value. > > Unfortunately, I lost track of who originally reported the issue. If > s/he is reading this, please speak up so I can give you the due credit. > > Signed-off-by: Wander Lairson Costa <wander@xxxxxxxxxx> > --- > drivers/tty/serial/8250/8250_port.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > index 4acf620be241..7e2227161555 100644 > --- a/drivers/tty/serial/8250/8250_port.c > +++ b/drivers/tty/serial/8250/8250_port.c > @@ -3416,6 +3416,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s, > !(up->capabilities & UART_CAP_MINI) && > up->tx_loadsz > 1 && > (up->fcr & UART_FCR_ENABLE_FIFO) && > + test_bit(TTY_PORT_INITIALIZED, &port->state->port.iflags) && > /* > * After we put a data in the fifo, the controller will send > * it regardless of the CTS state. Therefore, only use fifo So it looks like 2-5 just contain your development history and should all be merged to 1/5 (perhaps with Co-developed-by: tags where appropriate). And please don't just merge them "silently" there w/o describing in the message _why_ you ended up doing the things the way you did in the end. The messages you've written for patches 2-5 will serve you as great source material (with small mods, obviously). -- i.
