Re: [PATCH] serial: 8250_dw: Allow TX FIFO to drain before writing to UART_LCR An issue has been observed on the Broadcom BCM56160 serial port which appears closely related to a similar issue on the Marvell Armada 38x serial port.

[Ilpo Järvinen]

On Mon, 16 Oct 2023, Ilpo Järvinen wrote:

> On Mon, 16 Oct 2023, Richard Laing wrote:
> 
> Your subject line is way too long. If you refer to some other issue, 
> please link to it properly with commit id and/or with Link: tags.
> 
> > Writes to UART_LCR can result in characters that are currently held in the
> > TX FIFO being lost rather than sent, even if the userspace process has
> > attempted to flush them.
> > 
> > This is most visible when using the "resize" command (tested on Busybox),
> > where we have observed the escape code for restoring cursor position
> > becoming mangled.
> > 
> > Since this appears to be a more common problem add a new driver option
> > to flush the TX FIFO before writing to the UART_LCR.
> 
> This looks like a problem we already have solution for, the userspace can 
> use TCSADRAIN/FLUSH to indicate what kind of flushing it wants for Tx 
> when it makes the tcsetattr() call. Thus, userspace can avoid the Tx side 
> corruption as long as its behavior is sane and doesn't e.g. try to race 
> writes with tcsetattr() call as mentioned in commit 094fb49a2d0d ("tty: 
> Prevent writing chars during tcsetattr TCSADRAIN/FLUSH").

I'm sorry, it was actually mentioned in commit 146a37e05d62 ("serial: 
8250: Fix serial8250_tx_empty() race with DMA Tx") although that 
094fb49a2d0d is also related to the draining.

> Have you tried to use the userspace solution? Isn't it working for some 
> reason?

-- 
 i.