On 25.06.22 at 12:05, Ilpo Järvinen wrote: > On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > >> From: Lino Sanfilippo <l.sanfilippo@xxxxxxxxxx> >> >> When setting the RS485 configuration from userspace via TIOCSRS485 the >> delays are clamped to 100ms. Make this consistent with the values passed >> in by means of device tree parameters. >> >> Signed-off-by: Lino Sanfilippo <l.sanfilippo@xxxxxxxxxx> >> --- >> drivers/tty/serial/serial_core.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c >> index fa6acadd7d0c..2e9f90e73e62 100644 >> --- a/drivers/tty/serial/serial_core.c >> +++ b/drivers/tty/serial/serial_core.c >> @@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port) >> rs485conf->delay_rts_after_send = 0; >> } >> >> + uart_sanitize_serial_rs485_delays(port, rs485conf); >> + >> /* >> * Clear full-duplex and enabled flags, set RTS polarity to active high >> * to get to a defined state with the following properties: >> -- >> 2.36.1 > > While above works, if we go to this change user-visible behavior route, > uart_get_rs485_mode() could just call full uart_sanitize_serial_rs485()? As it is now uart_sanitize_serial_rs485() will clear the entire serial_rs485 struct and return immediately if rs485-enabled-at-boot-time (and thus SER_RS485_ENABLED) is not set. That was one of the reasons I moved the delay checks into an own fucntion. The other reason is that the remaining sanity check for RTS on send/after send in uart_sanitize_serial_rs485() is not required in uart_get_rs485_mode() since here we already ensure a sane setting. Regards, Lino
