Hi Lukas,
I've discovered a new issue with EM485 in 8250_omap (and probably other
serial drivers as well?): When closing the TTY device while there is
still an ongoing transmission, the RTS pin will get stuck active until
the TTY is opened again. This can be easily reproduced by running `cat
/dev/zero > /dev/ttySx` and then stopping it using Ctrl-C.
The issue exists in current mainline (6.1-rc5+), and applying "serial:
8250: 8250_omap: Avoid RS485 RTS glitch on ->set_termios()" from next
doesn't solve it. I think it should work with "serial: 8250: 8250_omap:
Support native RS485", but we also need RS485 on AM57xx CPUs, which
don't have native RS485.
I intend to look into this myself next week, but as you've worked on
this code a lot lately, maybe you already have an idea how to fix it?
Regards,
Matthias
On Fri, 2022-11-18 at 12:57 +0100, Matthias Schiffer wrote:
> Hi Lukas,
>
> I've discovered a new issue with EM485 in 8250_omap (and probably other
> serial drivers as well?): When closing the TTY device while there is
> still an ongoing transmission, the RTS pin will get stuck active until
> the TTY is opened again. This can be easily reproduced by running `cat
> /dev/zero > /dev/ttySx` and then stopping it using Ctrl-C.
>
> The issue exists in current mainline (6.1-rc5+), and applying "serial:
> 8250: 8250_omap: Avoid RS485 RTS glitch on ->set_termios()" from next
> doesn't solve it. I think it should work with "serial: 8250: 8250_omap:
> Support native RS485", but we also need RS485 on AM57xx CPUs, which
> don't have native RS485.
>
> I intend to look into this myself next week, but as you've worked on
> this code a lot lately, maybe you already have an idea how to fix it?
>
> Regards,
> Matthias
>
Okay, I've narrowed down the issue to uart_shutdown() ->
uart_port_shutdown() - here, ops->shutdown() is called, which clears
the FIFOs (in the case of the default 8250_port and 8250_omap)
implementations, but doesn't wait for the clear to finish, and doesn't
call ops->stop_tx().
I believe a similar problem can occur in uart_suspend_port(). Here,
ops->stop_tx() is called before ops->shutdown(), but stop_tx() is a no-
op when the TX FIFO is not empty (again, for the 8250 case - I haven't
really looked at other drivers).
Given that EM485 is handled in 8250_port by __stop_tx(), which is
called both internally in the 8250 driver and from the serial core
through stop_tx(), it is not clear to me what the correct layer to fix
this is. Two ideas:
(1) Have ops->shutdown() wait until the TX FIFO is empty. Call
ops->stop_tx() after ops->shutdown() in serial core. For this to work,
calling stop_tx() after shutdown() must be allowed in all drivers; I'm
not sure if this is currently the case, and if it is desirable at all.
(2) Do the whole handling in the driver's ops->shutdown(), do not
further involve the serial core.
So far, I've implemented (1) locally for 8250_omap, and together with
"serial: 8250: 8250_omap: Avoid RS485 RTS glitch on ->set_termios()" it
fixes the issue on my test devices, but I'm not too happy about the
"shutdown then tx_stop" order of calls. So maybe (2) is the better
solution after all?