| Message ID | 20220622154659.8710-5-LinoSanfilippo@gmx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fixes and cleanup for RS485 | expand |
On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > 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@kunbus.com> > --- > 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.
On 25.06.22 at 12:05, Ilpo Järvinen wrote: > On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> 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@kunbus.com> >> --- >> 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
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: