On 6/25/24 10:39 PM, Fabio Estevam wrote:
[Adding Christoph and Marek]
On Tue, Jun 25, 2024 at 3:42 PM Rasmus Villemoes
<linux@xxxxxxxxxxxxxxxxxx> wrote:
If a process is killed while writing to a /dev/ttymxc* device in RS485
mode, we observe that the RTS signal is left high, thus making it
impossible for other devices to transmit anything.
Moreover, the ->tx_state variable is left in state SEND, which means
that when one next opens the device and configures baud rate etc., the
initialization code in imx_uart_set_termios dutifully ensures the RTS
pin is pulled down, but since ->tx_state is already SEND, the logic in
imx_uart_start_tx() does not in fact pull the pin high before
transmitting, so nothing actually gets on the wire on the other side
of the transceiver. Only when that transmission is allowed to complete
is the state machine then back in a consistent state.
This is completely reproducible by doing something as simple as
seq 10000 > /dev/ttymxc0
and hitting ctrl-C, and watching with a logic analyzer.
Signed-off-by: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
---
v2: Use dev_warn() instead of dev_WARN_ONCE().
v1: https://lore.kernel.org/lkml/20240524121246.1896651-1-linux@xxxxxxxxxxxxxxxxxx/
A screen dump from a logic analyzer can be seen at:
https://ibb.co/xCcP7Jy
This is on an imx8mp board, with /dev/ttymxc0 and /dev/ttymxc2 both
configured for rs485 and connected to each other. I'm writing to
/dev/ttymxc2. This demonstrates both bugs; that RTS is left high when
a write is interrupted, and that a subsequent write actually fails to
have RTS high while TX'ing.
I'm not sure what commit to name as a Fixes:. This certainly happens
on 6.6 and onwards, but I assume the problem exists since the tx_state
machine was introduced in cb1a60923609 (serial: imx: implement rts
delaying for rs485), and possibly even before that.
Wow, thank you for the detailed analysis of the issue.
Reviewed-by: Marek Vasut <marex@xxxxxxx>
