[[PATCH] serial: 8250_fsl: Don't report FE, PE and OE twice] On 11/05/2022 (Wed 11:32) Uwe Kleine-König wrote:
> Some Freescale 8250 implementations have the problem that a single long
> break results in one irq per character frame time. The code in
> fsl8250_handle_irq() that is supposed to handle that uses the BI bit in
> lsr_saved_flags to detect such a situation and then skip the second
> received character. However it also stores other error bits and so after
> a single frame error the character received in the next irq handling is
> passed to the upper layer with a frame error, too.
>
> To weaken this problem restrict saving LSR to only the BI bit.
But what is missing is just what "this problem" is - what applications
are broken and how? What are the symptoms? This is a 15+ year old
platform and so one has to ask why this is just being seen now.
> Note however that the handling is still broken:
>
> - lsr_saved_flags is updated using orig_lsr which is the LSR content
> for the first received char, but there might be more in the FIFO, so
> a character is thrown away that is received later and not necessarily
> the one following the break.
> - The doubled break might be the 2nd and 3rd char in the FIFO, so the
> workaround doesn't catch these, because serial8250_rx_chars() doesn't
> handle the workaround.
> - lsr_saved_flags might have set UART_LSR_BI at the entry of
> fsl8250_handle_irq() which doesn't originate from
> fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr &
> UART_LSR_BI;" but from e.g. from serial8250_tx_empty().
> - For a long or a short break this isn't about two characters, but more
> or only a single one.
I've long since flushed the context required to parse the above, sorry.
But the part where it says "is still broken" stands out to me.
> Fixes: 9deaa53ac7fa ("serial: add irq handler for Freescale 16550 errata.")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
> ---
> Hello,
>
> note this patch is more or less untested because I have an MPC8313 that
> doesn't show the behaviour described in the erratum. However the patch
> fixes handling of frame errors, partity errors and overflow errors if
> for that SoC the fsl8250_handle_irq is still used (which is a different
> bug).
The commit log probably should indicate how these three types of errors
show up and how current mis-handling them is manifested in user visible
symptoms -- such as what you are seeing today.
The "untested" part is concerning, since this 2006 hardware is on the wrong
side of the bathtub curve and if you can't actually confirm that you've
not broken the original errata fix, well that isn't good.
I've done my best to recall what I can about this very old change in the
other parallel thread, so hopefully you can then reproduce it and then
reconcile what issues you are having without breaking the original fix.
Paul.
--
>
> drivers/tty/serial/8250/8250_fsl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
> index 9c01c531349d..71ce43685797 100644
> --- a/drivers/tty/serial/8250/8250_fsl.c
> +++ b/drivers/tty/serial/8250/8250_fsl.c
> @@ -77,7 +77,7 @@ int fsl8250_handle_irq(struct uart_port *port)
> if ((lsr & UART_LSR_THRE) && (up->ier & UART_IER_THRI))
> serial8250_tx_chars(up);
>
> - up->lsr_saved_flags = orig_lsr;
> + up->lsr_saved_flags |= orig_lsr & UART_LSR_BI;
>
> uart_unlock_and_check_sysrq_irqrestore(&up->port, flags);
>
>
> base-commit: 3123109284176b1532874591f7c81f3837bbdc17
> --
> 2.35.1
>
