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()? The sanitization is currently being done during probe in uart_rs485_config() which has another challenge to tackle. The RS485 supporting UART drivers are not consistently calling it during their probe(), only a few of them do but it would make more sense if all of them would enter into RS485 mode w/ linux,rs485-enabled-at-boot-time being set. However, making such change might run afoul with the expectations of users. -- i.
