Minimal patch against TI AM335x UART swallowing the first byte using the 8250_omap driver in RS485 mode

Commit Message

Falco Hyfing Nov. 8, 2019, 2:41 p.m. UTC

I stumbled upon this unresolved issue where the TI AM335x UART is 
sporadically swallowing the first byte using the 8250_omap driver in 
RS485 mode.

Previous discussions of the issue ended on Christmas Eve last year. For 
reference:
https://marc.info/?w=2&r=1&s=fix+clearing+fifos+rs485+mode+again&q=t

As our company plans to move our serial device servers' firmware to an 
upstream kernel version we need a solution for this problem.

I appended a small patch that seems to resolve the issue for our products.

I would like to kindly ask whether you could test this patch with 
various serial hardware that would be affected by this driver.

Kind regards,

     Falco Hyfing
     Software Engineer at VisionSystems GmbH


                 serial_port_out(&p->port, UART_IER, p->ier);

Comments

Marek Vasut Nov. 8, 2019, 3:45 p.m. UTC | #1

On 11/8/19 3:41 PM, Falco Hyfing wrote:

Hi,

> I stumbled upon this unresolved issue where the TI AM335x UART is
> sporadically swallowing the first byte using the 8250_omap driver in
> RS485 mode.
> 
> Previous discussions of the issue ended on Christmas Eve last year. For
> reference:
> https://marc.info/?w=2&r=1&s=fix+clearing+fifos+rs485+mode+again&q=t

Right, I'm sorry for not following up on that thread anymore. I was ill
during that time and I didn't have the energy to counter all those
negative emails. So thanks for picking this up.

I think the issue is a generic one though, and affects various other
16550 UARTs, it's not isolated to the OMAP UART, which is why I patched
the generic code. I think if we could solve the quirk of that JZ4780
UART, the generic approach would work.

> As our company plans to move our serial device servers' firmware to an
> upstream kernel version we need a solution for this problem.
> 
> I appended a small patch that seems to resolve the issue for our products.
> 
> I would like to kindly ask whether you could test this patch with
> various serial hardware that would be affected by this driver.
> 
> Kind regards,
> 
>     Falco Hyfing
>     Software Engineer at VisionSystems GmbH
> 
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c
> b/drivers/tty/serial/8250/8250_port.c
> index 8407166610ce..25dd44d5f6ff 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -1405,7 +1405,8 @@ static void __do_stop_tx_rs485(struct
> uart_8250_port *p)
>          * Enable previously disabled RX interrupts.
>          */
>         if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
> -               serial8250_clear_and_reinit_fifos(p);
> +               serial_port_out(&p->port, UART_FCR, p->fcr |
> +                               UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
> 
>                 p->ier |= UART_IER_RLSI | UART_IER_RDI;
>                 serial_port_out(&p->port, UART_IER, p->ier);
>

Patch

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 8407166610ce..25dd44d5f6ff 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1405,7 +1405,8 @@  static void __do_stop_tx_rs485(struct 
uart_8250_port *p)
          * Enable previously disabled RX interrupts.
          */
         if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
-               serial8250_clear_and_reinit_fifos(p);
+               serial_port_out(&p->port, UART_FCR, p->fcr |
+                               UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);

                 p->ier |= UART_IER_RLSI | UART_IER_RDI;