When an i.MX UART is opened in RS485 for reading only the serial core still calls uart_start at times which then calls .start_tx. In the i.MX case start_tx then asserts RTS to prepare sending data and only at the end notices that there is nothing to send and deassert RTS again. In the mean time some data sent to the i.MX might already be missed or damaged. Instead of fixing that in the driver, do it in the framework instead for other drivers to benefit. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> --- Hello, whenever I touch the serial core I feel that I don't understand all the interaction with the tty layer and the expectations of a driver. Is there something else that .start_tx is supposed to do such that it might make sense to call it even though the fifo is empty? Looking at atmel_serial.c I think it suffers the same problem because there the receiver is disabled, too, without first checking if there is something to send. So maybe I really miss something? On the bright side: With this change I can transmit data in both directions with my rs485 test setup between an i.MX6 and an i.MX25. Best regards Uwe drivers/tty/serial/serial_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index b4613aaf7a11..8ac2c1467a37 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -133,7 +133,8 @@ static void __uart_start(struct tty_struct *tty) struct uart_state *state = tty->driver_data; struct uart_port *port = state->uart_port; - if (port && !uart_tx_stopped(port)) + if (port && !uart_tx_stopped(port) && + (port->x_char || !uart_circ_empty(&port->state->xmit))) port->ops->start_tx(port); } -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
