| Message ID | 20220622154659.8710-1-LinoSanfilippo@gmx.de |
|---|---|
| Headers | show |
| Series | Fixes and cleanup for RS485 | expand |
On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus > termination is supported by the driver. I'm not sure I got the usefulness of this change. We request GPIO line as optional, so if one is defined it in the DT/ACPI, then they probably want to (opportunistically) have it. The certain driver may or may not utilize this GPIO. With your change it's possible to have a DTS where GPIO line defined in a broken way and user won't ever know about it, if they are using platforms without termination support.
On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > In serial8250_em485_config() the termination GPIO is set with the uart_port > spinlock held. This is an issue if setting the GPIO line can sleep (e.g. > since the concerning GPIO expander is connected via SPI or I2C). > > Fix this by setting the termination line outside of the uart_port spinlock > in the serial core. This doesn't describe that this patch is actually changing GPIO to support sleep mode. So, it doesn't fix anything. Please rephrase the commit message accordingly. > This also makes setting the termination GPIO generic for all uart drivers. UART
Hi, On 22.06.22 at 19:04, Andy Shevchenko wrote: > On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus >> termination is supported by the driver. > > I'm not sure I got the usefulness of this change. > We request GPIO line as optional, so if one is defined it in the DT/ACPI, then > they probably want to (opportunistically) have it> > > With your change it's possible to have a DTS where GPIO line defined in a > broken way and user won't ever know about it, if they are using platforms > without termination support. > This behavior is not introduced with this patch, also in the current code the driver wont inform the user if it does not make use erroneous defined termination GPIO. This patch at least prevents the driver from allocating and holding a GPIO descriptor across the drivers lifetime that will never be used. Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can skip the check whether or not the termination GPIO is supported by the driver. Regards, Lino
On 22.06.22 at 19:06, Andy Shevchenko wrote: > On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote: >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> In serial8250_em485_config() the termination GPIO is set with the uart_port >> spinlock held. This is an issue if setting the GPIO line can sleep (e.g. >> since the concerning GPIO expander is connected via SPI or I2C). >> >> Fix this by setting the termination line outside of the uart_port spinlock >> in the serial core. > > This doesn't describe that this patch is actually changing GPIO to support > sleep mode. So, it doesn't fix anything. Please rephrase the commit message > accordingly. Good point, I will adjust the commit message in the next version. >> This also makes setting the termination GPIO generic for all uart drivers. > > UART > Right, upper letters should be used. Thanks a lot for the review! Regards, Lino
On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote: > On 22.06.22 at 19:04, Andy Shevchenko wrote: > > On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > >> > >> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus > >> termination is supported by the driver. > > > > I'm not sure I got the usefulness of this change. > > We request GPIO line as optional, so if one is defined it in the DT/ACPI, then > > they probably want to (opportunistically) have it> > > > > With your change it's possible to have a DTS where GPIO line defined in a > > broken way and user won't ever know about it, if they are using platforms > > without termination support. > > This behavior is not introduced with this patch, also in the current code the driver > wont inform the user if it does not make use erroneous defined termination GPIO. It does. If a previously stale GPIO resource may have deferred a probe and hence one may debug why the driver is not working, after this change one may put a stale GPIO resource into DT/ACPI and have nothing in the result. Meaning the change relaxes validation which I consider is not good. > This patch at least prevents the driver from allocating and holding a GPIO descriptor across > the drivers lifetime that will never be used. But it's not your issue, if DTS defines it, so the platform has an idea about its usage. > Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can > skip the check whether or not the termination GPIO is supported by the driver. That's fine.
On 23.06.22 at 11:45, Andy Shevchenko wrote: > On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote: >> On 22.06.22 at 19:04, Andy Shevchenko wrote: >>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: >>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >>>> >>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus >>>> termination is supported by the driver. >>> >>> I'm not sure I got the usefulness of this change. >>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then >>> they probably want to (opportunistically) have it> >>> >>> With your change it's possible to have a DTS where GPIO line defined in a >>> broken way and user won't ever know about it, if they are using platforms >>> without termination support. >> >> This behavior is not introduced with this patch, also in the current code the driver >> wont inform the user if it does not make use erroneous defined termination GPIO. > > It does. If a previously stale GPIO resource may have deferred a probe > and hence one may debug why the driver is not working, after this > change one may put a stale GPIO resource into DT/ACPI and have nothing > in the result. Meaning the change relaxes validation which I consider > is not good. > Ok I see the point. So what about changing it to: if (port->rs485_term_gpio && !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) { dev_warn(port->dev, "%s (%d): RS485 termination gpio not supported by driver\n", port->name, port->line); devm_gpiod_put(dev, port->rs485_term_gpio); port->rs485_term_gpio = NULL; } This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid RS485 settings. Regards, Lino
On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485() > into the new function uart_sanitize_serial_rs485_delays(). ... > + /* pick sane settings if the user hasn't */ Be consistent with the style (capitalization) of one-line comments. It might require another patch to make it all consistent. (Below is left for a context) > /* Return clean padding area to userspace */
On Thu, Jun 23, 2022 at 06:08:56PM +0200, Lino Sanfilippo wrote: > On 23.06.22 at 11:45, Andy Shevchenko wrote: > > On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote: > >> On 22.06.22 at 19:04, Andy Shevchenko wrote: > >>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: > >>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > >>>> > >>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus > >>>> termination is supported by the driver. > >>> > >>> I'm not sure I got the usefulness of this change. > >>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then > >>> they probably want to (opportunistically) have it> > >>> > >>> With your change it's possible to have a DTS where GPIO line defined in a > >>> broken way and user won't ever know about it, if they are using platforms > >>> without termination support. > >> > >> This behavior is not introduced with this patch, also in the current code the driver > >> wont inform the user if it does not make use erroneous defined termination GPIO. > > > > It does. If a previously stale GPIO resource may have deferred a probe > > and hence one may debug why the driver is not working, after this > > change one may put a stale GPIO resource into DT/ACPI and have nothing > > in the result. Meaning the change relaxes validation which I consider > > is not good. > > > > Ok I see the point. So what about changing it to: You mean adding below after the existing code in the module? > if (port->rs485_term_gpio && > !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) { > dev_warn(port->dev, > "%s (%d): RS485 termination gpio not supported by driver\n", > port->name, port->line); > devm_gpiod_put(dev, port->rs485_term_gpio); > port->rs485_term_gpio = NULL; > } > > This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid > RS485 settings. Probably it's okay, but I dunno we have much on this to gain. Users may start complaining of this (harmless) warning. I leave it to others to comment.
On 23.06.22 at 18:25, Andy Shevchenko wrote: > On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote: >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485() >> into the new function uart_sanitize_serial_rs485_delays(). > > ... > >> + /* pick sane settings if the user hasn't */ > > Be consistent with the style (capitalization) of one-line comments. Ok, I will adjust this. > (Below is left for a context) > >> /* Return clean padding area to userspace */ > Regards, Lino
On 23.06.22 at 18:32, Andy Shevchenko wrote: >> >> Ok I see the point. So what about changing it to: > > You mean adding below after the existing code in the module? Right, to be more precise between getting the gpio and the error check: port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term", GPIOD_OUT_LOW); if (port->rs485_term_gpio && !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) { dev_warn(port->dev, "%s (%d): RS485 termination gpio not supported by driver\n", port->name, port->line); devm_gpiod_put(dev, port->rs485_term_gpio); port->rs485_term_gpio = NULL; } if (IS_ERR(port->rs485_term_gpio)) { ret = PTR_ERR(port->rs485_term_gpio); port->rs485_term_gpio = NULL; return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n"); } Regards, Lino > >> if (port->rs485_term_gpio && >> !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) { >> dev_warn(port->dev, >> "%s (%d): RS485 termination gpio not supported by driver\n", >> port->name, port->line); >> devm_gpiod_put(dev, port->rs485_term_gpio); >> port->rs485_term_gpio = NULL; >> } >> >> This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid >> RS485 settings. > > Probably it's okay, but I dunno we have much on this to gain. Users may start > complaining of this (harmless) warning. I leave it to others to comment. >
On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485() > into the new function uart_sanitize_serial_rs485_delays(). > > Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
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 Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > In uart_set_rs485_config() the serial core already assigns the passed > serial_rs485 struct to the uart port. > > So remove the assignment in the drivers rs485_config() function to avoid > redundancy. > > Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> > --- > drivers/tty/serial/ar933x_uart.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c > index ab2c5b2a1ce8..857e010d01dc 100644 > --- a/drivers/tty/serial/ar933x_uart.c > +++ b/drivers/tty/serial/ar933x_uart.c > @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port, > dev_err(port->dev, "RS485 needs rts-gpio\n"); > return 1; > } > - port->rs485 = *rs485conf; > return 0; > } Hmm, I realize that for some reason I missed cleaning up this particular driver after introducing the serial_rs485 sanitization. It shouldn't need that preceeding if block either because ar933x_no_rs485 gets applied if there's no rts_gpiod so the core clears SER_RS485_ENABLED.
On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > Before the drivers rs485_config() function is called the serial core > already ensures that only one of both options RTS on send or RTS after send > is set. So remove the concerning sanity check in the driver function to > avoid redundancy. > > Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > Before the drivers rs485_config() function is called the serial core > already ensures that only one of both options RTS on send or RTS after send > is set. So remove the concerning sanity check in the driver function to > avoid redundancy. > > Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> > --- > drivers/tty/serial/8250/8250_dwlib.c | 10 ++-------- > 1 file changed, 2 insertions(+), 8 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c > index c83e7eaf3877..bed2bd6b7a01 100644 > --- a/drivers/tty/serial/8250/8250_dwlib.c > +++ b/drivers/tty/serial/8250/8250_dwlib.c > @@ -95,16 +95,10 @@ static int dw8250_rs485_config(struct uart_port *p, struct serial_rs485 *rs485) > if (rs485->flags & SER_RS485_ENABLED) { > tcr |= DW_UART_TCR_RS485_EN; > > - if (rs485->flags & SER_RS485_RX_DURING_TX) { > + if (rs485->flags & SER_RS485_RX_DURING_TX) > tcr |= DW_UART_TCR_XFER_MODE_DE_DURING_RE; > - } else { > - /* HW does not support same DE level for tx and rx */ > - if (!(rs485->flags & SER_RS485_RTS_ON_SEND) == > - !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) > - return -EINVAL; > - > + else > tcr |= DW_UART_TCR_XFER_MODE_DE_OR_RE; > - } > dw8250_writel_ext(p, DW_UART_DE_EN, 1); > dw8250_writel_ext(p, DW_UART_RE_EN, 1); > } else { > -- Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > In serial8250_em485_config() the termination GPIO is set with the uart_port > spinlock held. This is an issue if setting the GPIO line can sleep (e.g. > since the concerning GPIO expander is connected via SPI or I2C). > > Fix this by setting the termination line outside of the uart_port spinlock > in the serial core. > > This also makes setting the termination GPIO generic for all uart drivers. > > Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> > --- > drivers/tty/serial/8250/8250_port.c | 3 --- > drivers/tty/serial/serial_core.c | 12 ++++++++++++ > 2 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > index 3e3d784aa628..5245c179cc51 100644 > --- a/drivers/tty/serial/8250/8250_port.c > +++ b/drivers/tty/serial/8250/8250_port.c > @@ -675,9 +675,6 @@ int serial8250_em485_config(struct uart_port *port, struct serial_rs485 *rs485) > rs485->flags &= ~SER_RS485_RTS_AFTER_SEND; > } > > - gpiod_set_value(port->rs485_term_gpio, > - rs485->flags & SER_RS485_TERMINATE_BUS); > - > /* > * Both serial8250_em485_init() and serial8250_em485_destroy() > * are idempotent. > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c > index 015f4e1da647..b387376e6fa2 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -1352,12 +1352,23 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4 > memset(rs485->padding, 0, sizeof(rs485->padding)); > } > > +static void uart_set_rs485_termination(struct uart_port *port, > + const struct serial_rs485 *rs485) > +{ > + if (!port->rs485_term_gpio || !(rs485->flags & SER_RS485_ENABLED)) > + return; > + > + gpiod_set_value_cansleep(port->rs485_term_gpio, > + !!(rs485->flags & SER_RS485_TERMINATE_BUS)); > +} > + > int uart_rs485_config(struct uart_port *port) > { > struct serial_rs485 *rs485 = &port->rs485; > int ret; > > uart_sanitize_serial_rs485(port, rs485); > + uart_set_rs485_termination(port, rs485); > > ret = port->rs485_config(port, rs485); > if (ret) > @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port, > if (ret) > return ret; > uart_sanitize_serial_rs485(port, &rs485); > + uart_set_rs485_termination(port, &rs485); > > spin_lock_irqsave(&port->lock, flags); > ret = port->rs485_config(port, &rs485); When port->rs485_config(port, &rs485) returns non-zero, the input got partially applied?
On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: > In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus > termination is supported by the driver. [...] > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port) > rs485conf->flags |= SER_RS485_RTS_AFTER_SEND; > } > > - /* > - * Disabling termination by default is the safe choice: Else if many > - * bus participants enable it, no communication is possible at all. > - * Works fine for short cables and users may enable for longer cables. > - */ > - port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term", > - GPIOD_OUT_LOW); > - if (IS_ERR(port->rs485_term_gpio)) { > - ret = PTR_ERR(port->rs485_term_gpio); > - port->rs485_term_gpio = NULL; > - return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n"); > + if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) { So I think linux-next commit be2e2cb1d281 ("serial: Sanitize rs485_struct") contains a mistake in that it forces drivers to set SER_RS485_TERMINATE_BUS in their rs485_supported->flags to allow enabling bus termination. That's wrong because *every* rs485-capable driver can enable bus termination if a GPIO has been defined for that in the DT. In fact, another commit which was applied as part of the same series, ebe2cf736a04 ("serial: pl011: Fill in rs485_supported") does not set SER_RS485_TERMINATE_BUS in amba-pl011.c's flags and thus forbids the driver from enabling bus termination, even though we know there are products out there which support bus termination on the pl011 through a GPIO (Revolution Pi RevPi Compact, Revpi Flat). I think what you want to do is amend uart_get_rs485_mode() to set SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO was found in the DT. Instead of the change proposed above. Thanks, Lukas
On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote: > From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > > In serial8250_em485_config() the termination GPIO is set with the uart_port > spinlock held. This is an issue if setting the GPIO line can sleep (e.g. > since the concerning GPIO expander is connected via SPI or I2C). > > Fix this by setting the termination line outside of the uart_port spinlock > in the serial core. [...] > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port, > if (ret) > return ret; > uart_sanitize_serial_rs485(port, &rs485); > + uart_set_rs485_termination(port, &rs485); > > spin_lock_irqsave(&port->lock, flags); > ret = port->rs485_config(port, &rs485); That's one way to solve the issue. Another would be to push acquisition of the port spinlock down into drivers. I think in most drivers we don't need to take the port spinlock at all or only for a few specific register accesses. So taking the lock here in the midlayer is likely unwarranted. However, changing that requires going through every single driver's ->rs485_config() callback and checking whether it needs the lock or not. That's painful, but unavoidable in the long run. This patch just kicks the can down the road... Thanks, Lukas
On 25.06.22 at 21:58, Lukas Wunner wrote: > On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote: >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> In serial8250_em485_config() the termination GPIO is set with the uart_port >> spinlock held. This is an issue if setting the GPIO line can sleep (e.g. >> since the concerning GPIO expander is connected via SPI or I2C). >> >> Fix this by setting the termination line outside of the uart_port spinlock >> in the serial core. > [...] >> --- a/drivers/tty/serial/serial_core.c >> +++ b/drivers/tty/serial/serial_core.c >> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port, >> if (ret) >> return ret; >> uart_sanitize_serial_rs485(port, &rs485); >> + uart_set_rs485_termination(port, &rs485); >> >> spin_lock_irqsave(&port->lock, flags); >> ret = port->rs485_config(port, &rs485); > > That's one way to solve the issue. Another would be to push > acquisition of the port spinlock down into drivers. > > I think in most drivers we don't need to take the port spinlock at all > or only for a few specific register accesses. So taking the lock here > in the midlayer is likely unwarranted. However, changing that requires > going through every single driver's ->rs485_config() callback and > checking whether it needs the lock or not. As a first step its sufficient to take the lock in each drivers rs485_config() function and remove it from uart_set_rs485_config(). Then after time sort out the drivers that dont require the lock and remove it from their function. However the point of this patch was also to generalize the handling of the termination GPIO, so I would still see this placed in uart_set_rs485_config(). Regards, Lino
On 25.06.22 at 12:14, Ilpo Järvinen wrote: > On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> >> In uart_set_rs485_config() the serial core already assigns the passed >> serial_rs485 struct to the uart port. >> >> So remove the assignment in the drivers rs485_config() function to avoid >> redundancy. >> >> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> >> --- >> drivers/tty/serial/ar933x_uart.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c >> index ab2c5b2a1ce8..857e010d01dc 100644 >> --- a/drivers/tty/serial/ar933x_uart.c >> +++ b/drivers/tty/serial/ar933x_uart.c >> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port, >> dev_err(port->dev, "RS485 needs rts-gpio\n"); >> return 1; >> } >> - port->rs485 = *rs485conf; >> return 0; >> } > > Hmm, I realize that for some reason I missed cleaning up this particular > driver after introducing the serial_rs485 sanitization. It shouldn't need > that preceeding if block either because ar933x_no_rs485 gets applied if > there's no rts_gpiod so the core clears SER_RS485_ENABLED. > I think we still need that "if" in case that RS485 was not enabled at driver startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then RS485 is enabled via TIOCSRS485. Maybe in ar933x_uart_probe() if ((port->rs485.flags & SER_RS485_ENABLED) && !up->rts_gpiod) { dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); port->rs485.flags &= ~SER_RS485_ENABLED; port->rs485_supported = &ar933x_no_rs485; } should rather be if (!up->rts_gpiod) { dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); port->rs485.flags &= ~SER_RS485_ENABLED; port->rs485_supported = &ar933x_no_rs485; } Regards, Lino
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
Hi, On 25.06.22 at 12:40, Ilpo Järvinen wrote: >> + >> int uart_rs485_config(struct uart_port *port) >> { >> struct serial_rs485 *rs485 = &port->rs485; >> int ret; >> >> uart_sanitize_serial_rs485(port, rs485); >> + uart_set_rs485_termination(port, rs485); >> >> ret = port->rs485_config(port, rs485); >> if (ret) >> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port, >> if (ret) >> return ret; >> uart_sanitize_serial_rs485(port, &rs485); >> + uart_set_rs485_termination(port, &rs485); >> >> spin_lock_irqsave(&port->lock, flags); >> ret = port->rs485_config(port, &rs485); > > When port->rs485_config(port, &rs485) returns non-zero, the input got > partially applied? > > The thing is we dont know what the state of the termination GPIO (asserted or deasserted) was before we set it and port->rs485_config() failed, so we cannot restore it. We could read the GPIO before we change it but AFAIK this is unsafe since it is an output pin. Maybe add a boolean variable "rs485_termination_gpio_asserted" to uart_port to track the current state? Regards, Lino
On Sun, 26 Jun 2022, Lino Sanfilippo wrote: > On 25.06.22 at 12:14, Ilpo Järvinen wrote: > > On Wed, 22 Jun 2022, Lino Sanfilippo wrote: > > > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > >> > >> In uart_set_rs485_config() the serial core already assigns the passed > >> serial_rs485 struct to the uart port. > >> > >> So remove the assignment in the drivers rs485_config() function to avoid > >> redundancy. > >> > >> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> > >> --- > >> drivers/tty/serial/ar933x_uart.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c > >> index ab2c5b2a1ce8..857e010d01dc 100644 > >> --- a/drivers/tty/serial/ar933x_uart.c > >> +++ b/drivers/tty/serial/ar933x_uart.c > >> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port, > >> dev_err(port->dev, "RS485 needs rts-gpio\n"); > >> return 1; > >> } > >> - port->rs485 = *rs485conf; > >> return 0; > >> } > > > > Hmm, I realize that for some reason I missed cleaning up this particular > > driver after introducing the serial_rs485 sanitization. It shouldn't need > > that preceeding if block either because ar933x_no_rs485 gets applied if > > there's no rts_gpiod so the core clears SER_RS485_ENABLED. > > I think we still need that "if" in case that RS485 was not enabled at driver > startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then > RS485 is enabled via TIOCSRS485. > > Maybe in ar933x_uart_probe() > > if ((port->rs485.flags & SER_RS485_ENABLED) && > !up->rts_gpiod) { > dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); > port->rs485.flags &= ~SER_RS485_ENABLED; > port->rs485_supported = &ar933x_no_rs485; > } > > should rather be I think it would be better (and what I should have done while moving the check there in the first place but I missed it). In addition, however, it would be useful to not print unnecessarily: > if (!up->rts_gpiod) { if (port->rs485.flags & SER_RS485_ENABLED) { > dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); > port->rs485.flags &= ~SER_RS485_ENABLED; } > port->rs485_supported = &ar933x_no_rs485; > }
On Sat, 25 Jun 2022, Lukas Wunner wrote: > On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote: > > In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus > > termination is supported by the driver. > [...] > > --- a/drivers/tty/serial/serial_core.c > > +++ b/drivers/tty/serial/serial_core.c > > @@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port) > > rs485conf->flags |= SER_RS485_RTS_AFTER_SEND; > > } > > > > - /* > > - * Disabling termination by default is the safe choice: Else if many > > - * bus participants enable it, no communication is possible at all. > > - * Works fine for short cables and users may enable for longer cables. > > - */ > > - port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term", > > - GPIOD_OUT_LOW); > > - if (IS_ERR(port->rs485_term_gpio)) { > > - ret = PTR_ERR(port->rs485_term_gpio); > > - port->rs485_term_gpio = NULL; > > - return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n"); > > + if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) { > > So I think linux-next commit be2e2cb1d281 ("serial: Sanitize rs485_struct") > contains a mistake in that it forces drivers to set SER_RS485_TERMINATE_BUS > in their rs485_supported->flags to allow enabling bus termination. > > That's wrong because *every* rs485-capable driver can enable bus > termination if a GPIO has been defined for that in the DT. Do you mean every em485 using driver? Otherwise I don't see this "forces drivers to set" happening anywhere in the code? You're partially right because there are other bugs in this area such as the one you propose a fix below. While I was making the sanitization series, I entirely missed some parts related to termination because SER_RS485_TERMINATE_BUS is seemingly not set/handled correctly by the core. Another thing that looks a bug is that on subsequent call to TIOCSRS485, w/o SER_RS485_TERMINATE_BUS nothing happens (for non-em485 driver, that is)? It seems to be taken care by 2/8 of this series though, I think. But it should be properly marked as Fixes: ... in that case although nobody has complained about it so likely not a huge issue to anyone. > In fact, another commit which was applied as part of the same series, > ebe2cf736a04 ("serial: pl011: Fill in rs485_supported") does not set > SER_RS485_TERMINATE_BUS in amba-pl011.c's flags and thus forbids the > driver from enabling bus termination, even though we know there are > products out there which support bus termination on the pl011 through > a GPIO (Revolution Pi RevPi Compact, Revpi Flat). > > I think what you want to do is amend uart_get_rs485_mode() to set > SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO > was found in the DT. Instead of the change proposed above. That seems appropriate (and is a fix). What makes it a bit complicated though is that it's a pointer currently and what it points to is shared per driver (besides being const): const struct serial_rs485 *rs485_supported; While it could be embedded into uart_port, there's the .padding which we might not want to bloat uart_port with. Perhaps create non-uapi struct kserial_rs485 w/o .padding and add static_assert()s to ensure the layout is identical to serial_rs485?
On Sun, 26 Jun 2022, Lino Sanfilippo wrote: > On 25.06.22 at 21:58, Lukas Wunner wrote: > > On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote: > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> > >> > >> In serial8250_em485_config() the termination GPIO is set with the uart_port > >> spinlock held. This is an issue if setting the GPIO line can sleep (e.g. > >> since the concerning GPIO expander is connected via SPI or I2C). > >> > >> Fix this by setting the termination line outside of the uart_port spinlock > >> in the serial core. > > [...] > >> --- a/drivers/tty/serial/serial_core.c > >> +++ b/drivers/tty/serial/serial_core.c > >> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port, > >> if (ret) > >> return ret; > >> uart_sanitize_serial_rs485(port, &rs485); > >> + uart_set_rs485_termination(port, &rs485); > >> > >> spin_lock_irqsave(&port->lock, flags); > >> ret = port->rs485_config(port, &rs485); > > > > That's one way to solve the issue. Another would be to push > > acquisition of the port spinlock down into drivers. > > > > I think in most drivers we don't need to take the port spinlock at all > > or only for a few specific register accesses. So taking the lock here > > in the midlayer is likely unwarranted. However, changing that requires > > going through every single driver's ->rs485_config() callback and > > checking whether it needs the lock or not. > > As a first step its sufficient to take the lock in each drivers rs485_config() > function and remove it from uart_set_rs485_config(). Then after time sort out > the drivers that dont require the lock and remove it from their function. > > However the point of this patch was also to generalize the handling of the > termination GPIO, so I would still see this placed in uart_set_rs485_config(). Additional thing to consider is that core currently handles also the port->rs485 assignment under spinlock when ->rs485_config() was successful. TIOCSRS485 ioctl calls are synchronized by other primitives wrt. each other (port mutex and now also termios_rwsem) but drivers probably would like to see consistent rs485 which can only be realized by holding port->lock.
On 27.06.22 10:14, Ilpo Järvinen wrote: > On Sun, 26 Jun 2022, Lino Sanfilippo wrote: > >> On 25.06.22 at 12:14, Ilpo Järvinen wrote: >>> On Wed, 22 Jun 2022, Lino Sanfilippo wrote: >>> >>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com> >>>> >>>> In uart_set_rs485_config() the serial core already assigns the passed >>>> serial_rs485 struct to the uart port. >>>> >>>> So remove the assignment in the drivers rs485_config() function to avoid >>>> redundancy. >>>> >>>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> >>>> --- >>>> drivers/tty/serial/ar933x_uart.c | 1 - >>>> 1 file changed, 1 deletion(-) >>>> >>>> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c >>>> index ab2c5b2a1ce8..857e010d01dc 100644 >>>> --- a/drivers/tty/serial/ar933x_uart.c >>>> +++ b/drivers/tty/serial/ar933x_uart.c >>>> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port, >>>> dev_err(port->dev, "RS485 needs rts-gpio\n"); >>>> return 1; >>>> } >>>> - port->rs485 = *rs485conf; >>>> return 0; >>>> } >>> >>> Hmm, I realize that for some reason I missed cleaning up this particular >>> driver after introducing the serial_rs485 sanitization. It shouldn't need >>> that preceeding if block either because ar933x_no_rs485 gets applied if >>> there's no rts_gpiod so the core clears SER_RS485_ENABLED. >> >> I think we still need that "if" in case that RS485 was not enabled at driver >> startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then >> RS485 is enabled via TIOCSRS485. >> >> Maybe in ar933x_uart_probe() >> >> if ((port->rs485.flags & SER_RS485_ENABLED) && >> !up->rts_gpiod) { >> dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); >> port->rs485.flags &= ~SER_RS485_ENABLED; >> port->rs485_supported = &ar933x_no_rs485; >> } >> >> should rather be > > I think it would be better (and what I should have done while moving the > check there in the first place but I missed it). In addition, however, it > would be useful to not print unnecessarily: > >> if (!up->rts_gpiod) { > > if (port->rs485.flags & SER_RS485_ENABLED) { > >> dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n"); >> port->rs485.flags &= ~SER_RS485_ENABLED; > > } Right. I will send a fix for this with the new version of my series. Regards, Lino
Hi, On 27.06.22 11:05, Ilpo Järvinen wrote: > On Sat, 25 Jun 2022, Lukas Wunner wrote: >> >> I think what you want to do is amend uart_get_rs485_mode() to set >> SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO >> was found in the DT. Instead of the change proposed above. Agreed. > > That seems appropriate (and is a fix). > > What makes it a bit complicated though is that it's a pointer currently > and what it points to is shared per driver (besides being const): > const struct serial_rs485 *rs485_supported; > While it could be embedded into uart_port, there's the .padding which we > might not want to bloat uart_port with. Perhaps create non-uapi struct > kserial_rs485 w/o .padding and add static_assert()s to ensure the > layout is identical to serial_rs485? > > This seems to be indeed the cleanest solution. Regards, Lino
From: Lino Sanfilippo <l.sanfilippo@kunbus.com> The following series includes cleanup and fixes around RS485 in the serial core and uart drivers: Patch 1: Only request the rs485 termination gpio if it is supported. Patch 2: Set the rs485 termination GPIO in the serial core. This is needed since if the gpio is only accessible in sleepable context. It also is a further step to make the RS485 handling more generic. Patch 3: Move sanitizing of RS485 delays into an own function. This is in preparation of patch 4. Patch 4: Sanitize RS485 delays read from device tree. Patch 5: Correct RS485 delays in binding documentation. Patch 6: Remove redundant code in 8250_dwlib. Patch 7: Remove redundant code in ar933x. Patch 8: Remove redundant code in 8250-lpc18xx. This patchset is based tty-testing. Lino Sanfilippo (8): serial: core: only get RS485 termination gpio if supported serial: core, 8250: set RS485 termination gpio in serial core serial: core: move sanitizing of RS485 delays into own function serial: core: sanitize RS485 delays read from device tree dt_bindings: rs485: Correct delay values serial: 8250_dwlib: remove redundant sanity check for RS485 flags serial: ar933x: Remove redundant assignment in rs485_config serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags .../devicetree/bindings/serial/rs485.yaml | 4 +- drivers/tty/serial/8250/8250_dwlib.c | 10 +-- drivers/tty/serial/8250/8250_lpc18xx.c | 6 +- drivers/tty/serial/8250/8250_port.c | 3 - drivers/tty/serial/ar933x_uart.c | 1 - drivers/tty/serial/serial_core.c | 85 ++++++++++++------- 6 files changed, 59 insertions(+), 50 deletions(-) base-commit: df36f3e3fbb76d30d623a1623e31e3ce9c2fa750