The following series includes some fixes and improvements around RS485 in
the serial core and UART drivers:
Patch 1: Do not hold the port lock when setting rx-during-tx GPIO
Patch 2: Get rid of useless wrapper pl011_get_rs485_mode()
Patch 3: set missing supported flag for RX during TX GPIO
Patch 4: fix sanitizing check for RTS settings
Patch 5: make sure RS485 is cannot be enabled when it is not supported
Patch 6: imx: do not set RS485 enabled if it is not supported
Patch 7: omap: do not override settings for rs485 support
Changes in v2:
- add missing 'Fixes' tags as requested by Greg
- corrected a typo as pointed out by Hugo
- fix issue in imx driver in the serial core as suggested by Uwe
- partly rephrase some commit messages
- add patch 7
Changes in v3
- Drop patch "Get rid of useless wrapper pl011_get_rs485_mode()" as
requested by Greg
Lino Sanfilippo (6):
serial: Do not hold the port lock when setting rx-during-tx GPIO
serial: core: set missing supported flag for RX during TX GPIO
serial: core: fix sanitizing check for RTS settings
serial: core: make sure RS485 cannot be enabled when it is not
supported
serial: core, imx: do not set RS485 enabled if it is not supported
serial: omap: do not override settings for RS485 support
drivers/tty/serial/imx.c | 8 ------
drivers/tty/serial/omap-serial.c | 8 +++---
drivers/tty/serial/serial_core.c | 48 ++++++++++++++++++++++----------
drivers/tty/serial/stm32-usart.c | 5 +---
4 files changed, 38 insertions(+), 31 deletions(-)
base-commit: 94f6f0550c625fab1f373bb86a6669b45e9748b3
--
2.40.1
Both the imx and stm32 driver set the rx-during-tx GPIO in the
rs485_config() function by means of gpiod_set_value(). Since rs485_config()
is called with the port lock held, this can be an problem in case that
setting the GPIO line can sleep (e.g. if a GPIO expander is used which is
connected via SPI or I2C).
Avoid this issue by setting the GPIO outside of the port lock in the serial
core and by using gpiod_set_value_cansleep() instead of gpiod_set_value().
Since now both the term and the rx-during-tx GPIO are set within the serial
core use a common function uart_set_rs485_gpios() to set both.
With moving it into the serial core setting the rx-during-tx GPIO is now
automatically done for all drivers that support such a GPIO.
Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO")
Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO")
Cc: [email protected]
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/imx.c | 4 ----
drivers/tty/serial/serial_core.c | 10 ++++++----
drivers/tty/serial/stm32-usart.c | 5 +----
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 13cb78340709..edb2ec6a5567 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1947,10 +1947,6 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio
rs485conf->flags & SER_RS485_RX_DURING_TX)
imx_uart_start_rx(port);
- if (port->rs485_rx_during_tx_gpio)
- gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
- !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
-
return 0;
}
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 7bdc21d5e13b..ef0500be3553 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1391,14 +1391,16 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
memset(rs485->padding1, 0, sizeof(rs485->padding1));
}
-static void uart_set_rs485_termination(struct uart_port *port,
- const struct serial_rs485 *rs485)
+static void uart_set_rs485_gpios(struct uart_port *port,
+ const struct serial_rs485 *rs485)
{
if (!(rs485->flags & SER_RS485_ENABLED))
return;
gpiod_set_value_cansleep(port->rs485_term_gpio,
!!(rs485->flags & SER_RS485_TERMINATE_BUS));
+ gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
+ !!(rs485->flags & SER_RS485_RX_DURING_TX));
}
static int uart_rs485_config(struct uart_port *port)
@@ -1407,7 +1409,7 @@ static int uart_rs485_config(struct uart_port *port)
int ret;
uart_sanitize_serial_rs485(port, rs485);
- uart_set_rs485_termination(port, rs485);
+ uart_set_rs485_gpios(port, rs485);
ret = port->rs485_config(port, NULL, rs485);
if (ret)
@@ -1449,7 +1451,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port,
if (ret)
return ret;
uart_sanitize_serial_rs485(port, &rs485);
- uart_set_rs485_termination(port, &rs485);
+ uart_set_rs485_gpios(port, &rs485);
spin_lock_irqsave(&port->lock, flags);
ret = port->rs485_config(port, &tty->termios, &rs485);
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 5e9cf0c48813..8eb13bf055f2 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -226,10 +226,7 @@ static int stm32_usart_config_rs485(struct uart_port *port, struct ktermios *ter
stm32_usart_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
- if (port->rs485_rx_during_tx_gpio)
- gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
- !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
- else
+ if (!port->rs485_rx_during_tx_gpio)
rs485conf->flags |= SER_RS485_RX_DURING_TX;
if (rs485conf->flags & SER_RS485_ENABLED) {
--
2.40.1
If the imx driver cannot support RS485 it sets the ports rs485_supported
structure to NULL. But it still calls uart_get_rs485_mode() which may set
the RS485_ENABLED flag nevertheless.
This may lead to an attempt to configure RS485 even if it is not supported
when the flag is evaluated in uart_configure_port() at port startup.
Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED
flag is not supported by the caller.
With this fix a check for RTS availability is now obsolete in the imx
driver, since it can not evaluate to true any more. Remove this check, too.
Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported")
Cc: [email protected]
Suggested-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/imx.c | 4 ----
drivers/tty/serial/serial_core.c | 3 +++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index edb2ec6a5567..c8c19bf8585d 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2332,10 +2332,6 @@ static int imx_uart_probe(struct platform_device *pdev)
return ret;
}
- if (sport->port.rs485.flags & SER_RS485_ENABLED &&
- (!sport->have_rtscts && !sport->have_rtsgpio))
- dev_err(&pdev->dev, "no RTS control, disabling rs485\n");
-
/*
* If using the i.MX UART RTS/CTS control then the RTS (CTS_B)
* signal cannot be set low during transmission in case the
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index dca09877fabc..95cec2343b35 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3576,6 +3576,9 @@ int uart_get_rs485_mode(struct uart_port *port)
int ret;
int rx_during_tx_gpio_flag;
+ if (!(port->rs485_supported.flags & SER_RS485_ENABLED))
+ return 0;
+
ret = device_property_read_u32_array(dev, "rs485-rts-delay",
rs485_delay, 2);
if (!ret) {
--
2.40.1
Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
settings in a RS485 configuration that has been passed by userspace.
If RTS-on-send and RTS-after-send are both set or unset the configuration
is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
This however makes only sense if both RTS modes are actually supported by
the driver.
With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
take the driver support into account but only checks if one of both RTS
modes are supported. This may lead to the errorneous result of RTS-on-send
being set even if only RTS-after-send is supported.
Fix this by changing the implemented logic: First clear all unsupported
flags in the RS485 configuration, then adjust an invalid RTS setting by
taking into account which RTS mode is supported.
Cc: [email protected]
Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 697c36dc7ec8..f4feebf8200f 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
return;
}
+ rs485->flags &= supported_flags;
+
/* Pick sane settings if the user hasn't */
- if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
- !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
+ if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
!(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
- dev_warn_ratelimited(port->dev,
- "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
- port->name, port->line);
- rs485->flags |= SER_RS485_RTS_ON_SEND;
- rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
- supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
- }
+ if (supported_flags & SER_RS485_RTS_ON_SEND) {
+ rs485->flags |= SER_RS485_RTS_ON_SEND;
+ rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
- rs485->flags &= supported_flags;
+ dev_warn_ratelimited(port->dev,
+ "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
+ port->name, port->line);
+ } else {
+ rs485->flags |= SER_RS485_RTS_AFTER_SEND;
+ rs485->flags &= ~SER_RS485_RTS_ON_SEND;
+
+ dev_warn_ratelimited(port->dev,
+ "%s (%d): invalid RTS setting, using RTS_AFTER_SEND instead\n",
+ port->name, port->line);
+ }
+ }
uart_sanitize_serial_rs485_delays(port, rs485);
--
2.40.1
In serial_omap_rs485() RS485 support may be deactivated due to a missing
RTS GPIO. This is done by nullifying the ports rs485_supported struct.
After that however the serial_omap_rs485_supported struct is assigned to
the same structure unconditionally, which results in an unintended
reactivation of RS485 support.
Fix this by callling serial_omap_rs485() after the assignment of
rs485_supported.
Fixes: e2752ae3cfc9 ("serial: omap: Disallow RS-485 if rts-gpio is not specified")
Cc: [email protected]
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/omap-serial.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0ead88c5a19a..4f7ee4392034 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1604,10 +1604,6 @@ static int serial_omap_probe(struct platform_device *pdev)
dev_info(up->port.dev, "no wakeirq for uart%d\n",
up->port.line);
- ret = serial_omap_probe_rs485(up, &pdev->dev);
- if (ret < 0)
- goto err_rs485;
-
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = base;
@@ -1622,6 +1618,10 @@ static int serial_omap_probe(struct platform_device *pdev)
DEFAULT_CLK_SPEED);
}
+ ret = serial_omap_probe_rs485(up, &pdev->dev);
+ if (ret < 0)
+ goto err_rs485;
+
up->latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE;
up->calc_latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE;
cpu_latency_qos_add_request(&up->pm_qos_request, up->latency);
--
2.40.1
Some uart drivers specify a rs485_config() function and then decide later
to disable RS485 support for some reason (e.g. imx and ar933).
In these cases userspace may be able to activate RS485 via TIOCSRS485
nevertheless, since in uart_set_rs485_config() an existing rs485_config()
function indicates that RS485 is supported.
Make sure that this is not longer possible by checking the uarts
rs485_supported.flags instead and bailing out if SER_RS485_ENABLED is not
set.
Furthermore instead of returning an empty structure return -ENOTTY if the
RS485 configuration is requested via TIOCGRS485 but RS485 is not supported.
This has a small impact on userspace visibility but it is consistent with
the -ENOTTY error for TIOCGRS485.
Fixes: e849145e1fdd ("serial: ar933x: Fill in rs485_supported")
Fixes: 55e18c6b6d42 ("serial: imx: Remove serial_rs485 sanitization")
Cc: [email protected]
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/serial_core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index f4feebf8200f..dca09877fabc 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1432,6 +1432,9 @@ static int uart_get_rs485_config(struct uart_port *port,
unsigned long flags;
struct serial_rs485 aux;
+ if (!(port->rs485_supported.flags & SER_RS485_ENABLED))
+ return -ENOTTY;
+
spin_lock_irqsave(&port->lock, flags);
aux = port->rs485;
spin_unlock_irqrestore(&port->lock, flags);
@@ -1449,7 +1452,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port,
int ret;
unsigned long flags;
- if (!port->rs485_config)
+ if (!(port->rs485_supported.flags & SER_RS485_ENABLED))
return -ENOTTY;
if (copy_from_user(&rs485, rs485_user, sizeof(*rs485_user)))
--
2.40.1
On Wed, 11 Oct 2023 20:15:39 +0200
Lino Sanfilippo <[email protected]> wrote:
> Both the imx and stm32 driver set the rx-during-tx GPIO in the
> rs485_config() function by means of gpiod_set_value(). Since rs485_config()
> is called with the port lock held, this can be an problem in case that
> setting the GPIO line can sleep (e.g. if a GPIO expander is used which is
> connected via SPI or I2C).
>
> Avoid this issue by setting the GPIO outside of the port lock in the serial
> core and by using gpiod_set_value_cansleep() instead of gpiod_set_value().
Hi Lino,
it seems to me that both drivers were already using
gpiod_set_value_cansleep()? Maybe update your commit
message if this is the case.
>
> Since now both the term and the rx-during-tx GPIO are set within the serial
> core use a common function uart_set_rs485_gpios() to set both.
>
> With moving it into the serial core setting the rx-during-tx GPIO is now
> automatically done for all drivers that support such a GPIO.
>
> Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO")
> Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO")
> Cc: [email protected]
> Signed-off-by: Lino Sanfilippo <[email protected]>
> ---
> drivers/tty/serial/imx.c | 4 ----
> drivers/tty/serial/serial_core.c | 10 ++++++----
> drivers/tty/serial/stm32-usart.c | 5 +----
> 3 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 13cb78340709..edb2ec6a5567 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1947,10 +1947,6 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio
> rs485conf->flags & SER_RS485_RX_DURING_TX)
> imx_uart_start_rx(port);
>
> - if (port->rs485_rx_during_tx_gpio)
> - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
> - !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
> -
> return 0;
> }
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 7bdc21d5e13b..ef0500be3553 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1391,14 +1391,16 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
> memset(rs485->padding1, 0, sizeof(rs485->padding1));
> }
>
> -static void uart_set_rs485_termination(struct uart_port *port,
> - const struct serial_rs485 *rs485)
> +static void uart_set_rs485_gpios(struct uart_port *port,
> + const struct serial_rs485 *rs485)
> {
> if (!(rs485->flags & SER_RS485_ENABLED))
> return;
>
> gpiod_set_value_cansleep(port->rs485_term_gpio,
> !!(rs485->flags & SER_RS485_TERMINATE_BUS));
> + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
> + !!(rs485->flags & SER_RS485_RX_DURING_TX));
> }
>
> static int uart_rs485_config(struct uart_port *port)
> @@ -1407,7 +1409,7 @@ static int uart_rs485_config(struct uart_port *port)
> int ret;
>
> uart_sanitize_serial_rs485(port, rs485);
> - uart_set_rs485_termination(port, rs485);
> + uart_set_rs485_gpios(port, rs485);
Suggestion: define a new function to handle rx_during_tx, to keep
uart_set_rs485_termination(), which is more self-documenting than
uart_set_rs485_gpios().
ex:
uart_set_rs485_termination(port, rs485);
+ uart_set_rs485_rx_during_tx(port, rs485);
Hugo.
>
> ret = port->rs485_config(port, NULL, rs485);
> if (ret)
> @@ -1449,7 +1451,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port,
> if (ret)
> return ret;
> uart_sanitize_serial_rs485(port, &rs485);
> - uart_set_rs485_termination(port, &rs485);
> + uart_set_rs485_gpios(port, &rs485);
>
> spin_lock_irqsave(&port->lock, flags);
> ret = port->rs485_config(port, &tty->termios, &rs485);
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> index 5e9cf0c48813..8eb13bf055f2 100644
> --- a/drivers/tty/serial/stm32-usart.c
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -226,10 +226,7 @@ static int stm32_usart_config_rs485(struct uart_port *port, struct ktermios *ter
>
> stm32_usart_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
>
> - if (port->rs485_rx_during_tx_gpio)
> - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
> - !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
> - else
> + if (!port->rs485_rx_during_tx_gpio)
> rs485conf->flags |= SER_RS485_RX_DURING_TX;
>
> if (rs485conf->flags & SER_RS485_ENABLED) {
> --
> 2.40.1
>
Hi,
On 12.10.23 00:36, Hugo Villeneuve wrote:
.
>
>
> On Wed, 11 Oct 2023 20:15:39 +0200
> Lino Sanfilippo <[email protected]> wrote:
>
>> Both the imx and stm32 driver set the rx-during-tx GPIO in the
>> rs485_config() function by means of gpiod_set_value(). Since rs485_config()
>> is called with the port lock held, this can be an problem in case that
>> setting the GPIO line can sleep (e.g. if a GPIO expander is used which is
>> connected via SPI or I2C).
>>
>> Avoid this issue by setting the GPIO outside of the port lock in the serial
>> core and by using gpiod_set_value_cansleep() instead of gpiod_set_value().
>
> Hi Lino,
> it seems to me that both drivers were already using
> gpiod_set_value_cansleep()? Maybe update your commit
> message if this is the case.
>
Right, I will fix this, thanks!
>>
>> Since now both the term and the rx-during-tx GPIO are set within the serial
>> core use a common function uart_set_rs485_gpios() to set both.
>>
>> With moving it into the serial core setting the rx-during-tx GPIO is now
>> automatically done for all drivers that support such a GPIO.
>>
>> Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO")
>> Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO")
>> Cc: [email protected]
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>> ---
>> drivers/tty/serial/imx.c | 4 ----
>> drivers/tty/serial/serial_core.c | 10 ++++++----
>> drivers/tty/serial/stm32-usart.c | 5 +----
>> 3 files changed, 7 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 13cb78340709..edb2ec6a5567 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -1947,10 +1947,6 @@ static int imx_uart_rs485_config(struct uart_port *port, struct ktermios *termio
>> rs485conf->flags & SER_RS485_RX_DURING_TX)
>> imx_uart_start_rx(port);
>>
>> - if (port->rs485_rx_during_tx_gpio)
>> - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
>> - !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
>> -
>> return 0;
>> }
>>
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index 7bdc21d5e13b..ef0500be3553 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -1391,14 +1391,16 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>> memset(rs485->padding1, 0, sizeof(rs485->padding1));
>> }
>>
>> -static void uart_set_rs485_termination(struct uart_port *port,
>> - const struct serial_rs485 *rs485)
>> +static void uart_set_rs485_gpios(struct uart_port *port,
>> + const struct serial_rs485 *rs485)
>> {
>> if (!(rs485->flags & SER_RS485_ENABLED))
>> return;
>>
>> gpiod_set_value_cansleep(port->rs485_term_gpio,
>> !!(rs485->flags & SER_RS485_TERMINATE_BUS));
>> + gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
>> + !!(rs485->flags & SER_RS485_RX_DURING_TX));
>> }
>>
>> static int uart_rs485_config(struct uart_port *port)
>> @@ -1407,7 +1409,7 @@ static int uart_rs485_config(struct uart_port *port)
>> int ret;
>>
>> uart_sanitize_serial_rs485(port, rs485);
>> - uart_set_rs485_termination(port, rs485);
>> + uart_set_rs485_gpios(port, rs485);
>
> Suggestion: define a new function to handle rx_during_tx, to keep
> uart_set_rs485_termination(), which is more self-documenting than
> uart_set_rs485_gpios().
>
> ex:
> uart_set_rs485_termination(port, rs485);
> + uart_set_rs485_rx_during_tx(port, rs485);
>
I admit that I do not like the function name uart_set_rs485_gpios() very much. As you said it is
less descriptive than e.g. uart_set_rs485_termination(). On the other hand the two functions you
suggested would always be called together, which reduces the benefit of having two separate functions.
Plus they are nothing more than wrappers around gpiod_set_value_cansleep() with the same additional
check for SER_RS485_ENABLED.
Let me think about a better name first.
Anyway, thanks a lot for the review!
Regards,
Lino
> Hugo.
>
>
>>
>> ret = port->rs485_config(port, NULL, rs485);
>> if (ret)
>> @@ -1449,7 +1451,7 @@ static int uart_set_rs485_config(struct tty_struct *tty, struct uart_port *port,
>> if (ret)
>> return ret;
>> uart_sanitize_serial_rs485(port, &rs485);
>> - uart_set_rs485_termination(port, &rs485);
>> + uart_set_rs485_gpios(port, &rs485);
>>
>> spin_lock_irqsave(&port->lock, flags);
>> ret = port->rs485_config(port, &tty->termios, &rs485);
>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
>> index 5e9cf0c48813..8eb13bf055f2 100644
>> --- a/drivers/tty/serial/stm32-usart.c
>> +++ b/drivers/tty/serial/stm32-usart.c
>> @@ -226,10 +226,7 @@ static int stm32_usart_config_rs485(struct uart_port *port, struct ktermios *ter
>>
>> stm32_usart_clr_bits(port, ofs->cr1, BIT(cfg->uart_enable_bit));
>>
>> - if (port->rs485_rx_during_tx_gpio)
>> - gpiod_set_value_cansleep(port->rs485_rx_during_tx_gpio,
>> - !!(rs485conf->flags & SER_RS485_RX_DURING_TX));
>> - else
>> + if (!port->rs485_rx_during_tx_gpio)
>> rs485conf->flags |= SER_RS485_RX_DURING_TX;
>>
>> if (rs485conf->flags & SER_RS485_ENABLED) {
>> --
>> 2.40.1
>>
On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
> settings in a RS485 configuration that has been passed by userspace.
> If RTS-on-send and RTS-after-send are both set or unset the configuration
> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
>
> This however makes only sense if both RTS modes are actually supported by
> the driver.
>
> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
> take the driver support into account but only checks if one of both RTS
> modes are supported. This may lead to the errorneous result of RTS-on-send
> being set even if only RTS-after-send is supported.
>
> Fix this by changing the implemented logic: First clear all unsupported
> flags in the RS485 configuration, then adjust an invalid RTS setting by
> taking into account which RTS mode is supported.
>
> Cc: [email protected]
> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
> Signed-off-by: Lino Sanfilippo <[email protected]>
> ---
> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 697c36dc7ec8..f4feebf8200f 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
> return;
> }
>
> + rs485->flags &= supported_flags;
> +
> /* Pick sane settings if the user hasn't */
> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
> - dev_warn_ratelimited(port->dev,
> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> - port->name, port->line);
> - rs485->flags |= SER_RS485_RTS_ON_SEND;
> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
> - }
> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
> + rs485->flags |= SER_RS485_RTS_ON_SEND;
> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>
> - rs485->flags &= supported_flags;
> + dev_warn_ratelimited(port->dev,
> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> + port->name, port->line);
> + } else {
> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
So if neither of the flags is supported, what will happen? You might want
add if after that else?
--
i.
Hi,
On 12.10.23 15:10, Ilpo Järvinen wrote:
>
>
> On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
>
>> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
>> settings in a RS485 configuration that has been passed by userspace.
>> If RTS-on-send and RTS-after-send are both set or unset the configuration
>> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
>>
>> This however makes only sense if both RTS modes are actually supported by
>> the driver.
>>
>> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
>> take the driver support into account but only checks if one of both RTS
>> modes are supported. This may lead to the errorneous result of RTS-on-send
>> being set even if only RTS-after-send is supported.
>>
>> Fix this by changing the implemented logic: First clear all unsupported
>> flags in the RS485 configuration, then adjust an invalid RTS setting by
>> taking into account which RTS mode is supported.
>>
>> Cc: [email protected]
>> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>> ---
>> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index 697c36dc7ec8..f4feebf8200f 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>> return;
>> }
>>
>> + rs485->flags &= supported_flags;
>> +
>> /* Pick sane settings if the user hasn't */
>> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
>> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
>> - dev_warn_ratelimited(port->dev,
>> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>> - port->name, port->line);
>> - rs485->flags |= SER_RS485_RTS_ON_SEND;
>> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
>> - }
>> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
>> + rs485->flags |= SER_RS485_RTS_ON_SEND;
>> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>>
>> - rs485->flags &= supported_flags;
>> + dev_warn_ratelimited(port->dev,
>> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>> + port->name, port->line);
>> + } else {
>> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
>> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
>
> So if neither of the flags is supported, what will happen? You might want
> add if after that else?
>
I would consider this a bug in the driver, as at least one of both modes
has to be supported. If the driver does not have at least one of both flags
set in rs485_supported.flags we could print a warning though. Would you prefer that?
Regards,
Lino
On Thu, 12 Oct 2023, Lino Sanfilippo wrote:
> On 12.10.23 15:10, Ilpo Järvinen wrote:
> > On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
> >
> >> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
> >> settings in a RS485 configuration that has been passed by userspace.
> >> If RTS-on-send and RTS-after-send are both set or unset the configuration
> >> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
> >>
> >> This however makes only sense if both RTS modes are actually supported by
> >> the driver.
> >>
> >> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
> >> take the driver support into account but only checks if one of both RTS
> >> modes are supported. This may lead to the errorneous result of RTS-on-send
> >> being set even if only RTS-after-send is supported.
> >>
> >> Fix this by changing the implemented logic: First clear all unsupported
> >> flags in the RS485 configuration, then adjust an invalid RTS setting by
> >> taking into account which RTS mode is supported.
> >>
> >> Cc: [email protected]
> >> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
> >> Signed-off-by: Lino Sanfilippo <[email protected]>
> >> ---
> >> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
> >> 1 file changed, 18 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> >> index 697c36dc7ec8..f4feebf8200f 100644
> >> --- a/drivers/tty/serial/serial_core.c
> >> +++ b/drivers/tty/serial/serial_core.c
> >> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
> >> return;
> >> }
> >>
> >> + rs485->flags &= supported_flags;
> >> +
> >> /* Pick sane settings if the user hasn't */
> >> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
> >> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> >> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> >> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
> >> - dev_warn_ratelimited(port->dev,
> >> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> >> - port->name, port->line);
> >> - rs485->flags |= SER_RS485_RTS_ON_SEND;
> >> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
> >> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
> >> - }
> >> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
> >> + rs485->flags |= SER_RS485_RTS_ON_SEND;
> >> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
> >>
> >> - rs485->flags &= supported_flags;
> >> + dev_warn_ratelimited(port->dev,
> >> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> >> + port->name, port->line);
> >> + } else {
> >> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
> >> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
> >
> > So if neither of the flags is supported, what will happen? You might want
> > add if after that else?
> >
>
> I would consider this a bug in the driver, as at least one of both modes
> has to be supported. If the driver does not have at least one of both flags
> set in rs485_supported.flags we could print a warning though. Would you prefer that?
8250_exar.c needs to fixed then? I was taking these as things one can
"configure" even if when there's support only for a one of them there's
not that much to configure. As there was neither in 8250_exar's code, I
didn't add either flag.
But I suppose your interpretation of those flag makes more sense.
--
i.
Hi Ilpo,
On 13.10.23 12:24, Ilpo Järvinen wrote:
> On Thu, 12 Oct 2023, Lino Sanfilippo wrote:
>> On 12.10.23 15:10, Ilpo Järvinen wrote:
>>> On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
>>>
>>>> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
>>>> settings in a RS485 configuration that has been passed by userspace.
>>>> If RTS-on-send and RTS-after-send are both set or unset the configuration
>>>> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
>>>>
>>>> This however makes only sense if both RTS modes are actually supported by
>>>> the driver.
>>>>
>>>> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
>>>> take the driver support into account but only checks if one of both RTS
>>>> modes are supported. This may lead to the errorneous result of RTS-on-send
>>>> being set even if only RTS-after-send is supported.
>>>>
>>>> Fix this by changing the implemented logic: First clear all unsupported
>>>> flags in the RS485 configuration, then adjust an invalid RTS setting by
>>>> taking into account which RTS mode is supported.
>>>>
>>>> Cc: [email protected]
>>>> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
>>>> Signed-off-by: Lino Sanfilippo <[email protected]>
>>>> ---
>>>> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
>>>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>>>> index 697c36dc7ec8..f4feebf8200f 100644
>>>> --- a/drivers/tty/serial/serial_core.c
>>>> +++ b/drivers/tty/serial/serial_core.c
>>>> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>>>> return;
>>>> }
>>>>
>>>> + rs485->flags &= supported_flags;
>>>> +
>>>> /* Pick sane settings if the user hasn't */
>>>> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
>>>> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>>>> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>>>> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
>>>> - dev_warn_ratelimited(port->dev,
>>>> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>>>> - port->name, port->line);
>>>> - rs485->flags |= SER_RS485_RTS_ON_SEND;
>>>> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>>>> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
>>>> - }
>>>> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
>>>> + rs485->flags |= SER_RS485_RTS_ON_SEND;
>>>> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>>>>
>>>> - rs485->flags &= supported_flags;
>>>> + dev_warn_ratelimited(port->dev,
>>>> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>>>> + port->name, port->line);
>>>> + } else {
>>>> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
>>>> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
>>>
>>> So if neither of the flags is supported, what will happen? You might want
>>> add if after that else?
>>>
>>
>> I would consider this a bug in the driver, as at least one of both modes
>> has to be supported. If the driver does not have at least one of both flags
>> set in rs485_supported.flags we could print a warning though. Would you prefer that?
>
> 8250_exar.c needs to fixed then?
I was taking these as things one can
> "configure" even if when there's support only for a one of them there's
> not that much to configure. As there was neither in 8250_exar's code, I
> didn't add either flag.
> But I suppose your interpretation of those flag makes more sense.
>
IMHO this is consistent with what we have in uart_get_rs485_mode(). This function
ensures that we have at least one RTS mode set (with default to RTS_ON_SEND). So
concerning 8250_exar.c, I think it should be fixed (havent noticed the missing
RTS mode though until you mentioned it). Would you like to provide a fix for this
or shall I include one into the next version of this series?
BR,
Lino
Ccing Uwe.
On 11.10.23 20:15, Lino Sanfilippo wrote:
> The following series includes some fixes and improvements around RS485 in
> the serial core and UART drivers:
>
> Patch 1: Do not hold the port lock when setting rx-during-tx GPIO
> Patch 2: Get rid of useless wrapper pl011_get_rs485_mode()
> Patch 3: set missing supported flag for RX during TX GPIO
> Patch 4: fix sanitizing check for RTS settings
> Patch 5: make sure RS485 is cannot be enabled when it is not supported
> Patch 6: imx: do not set RS485 enabled if it is not supported
> Patch 7: omap: do not override settings for rs485 support
>
> Changes in v2:
> - add missing 'Fixes' tags as requested by Greg
> - corrected a typo as pointed out by Hugo
> - fix issue in imx driver in the serial core as suggested by Uwe
> - partly rephrase some commit messages
> - add patch 7
>
> Changes in v3
> - Drop patch "Get rid of useless wrapper pl011_get_rs485_mode()" as
> requested by Greg
>
Sorry Uwe, you gave valuable input for the former version of this series and I
just noticed now that I forgot to Cc you for this version.
BR,
Lino
On Sat, 14 Oct 2023, Lino Sanfilippo wrote:
> On 13.10.23 12:24, Ilpo Järvinen wrote:
> > On Thu, 12 Oct 2023, Lino Sanfilippo wrote:
> >> On 12.10.23 15:10, Ilpo Järvinen wrote:
> >>> On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
> >>>
> >>>> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
> >>>> settings in a RS485 configuration that has been passed by userspace.
> >>>> If RTS-on-send and RTS-after-send are both set or unset the configuration
> >>>> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
> >>>>
> >>>> This however makes only sense if both RTS modes are actually supported by
> >>>> the driver.
> >>>>
> >>>> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
> >>>> take the driver support into account but only checks if one of both RTS
> >>>> modes are supported. This may lead to the errorneous result of RTS-on-send
> >>>> being set even if only RTS-after-send is supported.
> >>>>
> >>>> Fix this by changing the implemented logic: First clear all unsupported
> >>>> flags in the RS485 configuration, then adjust an invalid RTS setting by
> >>>> taking into account which RTS mode is supported.
> >>>>
> >>>> Cc: [email protected]
> >>>> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
> >>>> Signed-off-by: Lino Sanfilippo <[email protected]>
> >>>> ---
> >>>> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
> >>>> 1 file changed, 18 insertions(+), 10 deletions(-)
> >>>>
> >>>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> >>>> index 697c36dc7ec8..f4feebf8200f 100644
> >>>> --- a/drivers/tty/serial/serial_core.c
> >>>> +++ b/drivers/tty/serial/serial_core.c
> >>>> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
> >>>> return;
> >>>> }
> >>>>
> >>>> + rs485->flags &= supported_flags;
> >>>> +
> >>>> /* Pick sane settings if the user hasn't */
> >>>> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
> >>>> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> >>>> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> >>>> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
> >>>> - dev_warn_ratelimited(port->dev,
> >>>> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> >>>> - port->name, port->line);
> >>>> - rs485->flags |= SER_RS485_RTS_ON_SEND;
> >>>> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
> >>>> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
> >>>> - }
> >>>> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
> >>>> + rs485->flags |= SER_RS485_RTS_ON_SEND;
> >>>> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
> >>>>
> >>>> - rs485->flags &= supported_flags;
> >>>> + dev_warn_ratelimited(port->dev,
> >>>> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
> >>>> + port->name, port->line);
> >>>> + } else {
> >>>> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
> >>>> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
> >>>
> >>> So if neither of the flags is supported, what will happen? You might want
> >>> add if after that else?
> >>>
> >>
> >> I would consider this a bug in the driver, as at least one of both modes
> >> has to be supported. If the driver does not have at least one of both flags
> >> set in rs485_supported.flags we could print a warning though. Would you prefer that?
> >
> > 8250_exar.c needs to fixed then?
> I was taking these as things one can
> > "configure" even if when there's support only for a one of them there's
> > not that much to configure. As there was neither in 8250_exar's code, I
> > didn't add either flag.
>
> > But I suppose your interpretation of those flag makes more sense.
>
> IMHO this is consistent with what we have in uart_get_rs485_mode(). This function
> ensures that we have at least one RTS mode set (with default to RTS_ON_SEND). So
> concerning 8250_exar.c, I think it should be fixed (havent noticed the missing
> RTS mode though until you mentioned it). Would you like to provide a fix for this
> or shall I include one into the next version of this series?
Just create that fix yourself thank you and include it into your series,
I'm busy with other stuff currently.
--
i.
On 16.10.23 12:05, Ilpo Järvinen wrote:
> On Sat, 14 Oct 2023, Lino Sanfilippo wrote:
>> On 13.10.23 12:24, Ilpo Järvinen wrote:
>>> On Thu, 12 Oct 2023, Lino Sanfilippo wrote:
>>>> On 12.10.23 15:10, Ilpo Järvinen wrote:
>>>>> On Wed, 11 Oct 2023, Lino Sanfilippo wrote:
>>>>>
>>>>>> Among other things uart_sanitize_serial_rs485() tests the sanity of the RTS
>>>>>> settings in a RS485 configuration that has been passed by userspace.
>>>>>> If RTS-on-send and RTS-after-send are both set or unset the configuration
>>>>>> is adjusted and RTS-after-send is disabled and RTS-on-send enabled.
>>>>>>
>>>>>> This however makes only sense if both RTS modes are actually supported by
>>>>>> the driver.
>>>>>>
>>>>>> With commit be2e2cb1d281 ("serial: Sanitize rs485_struct") the code does
>>>>>> take the driver support into account but only checks if one of both RTS
>>>>>> modes are supported. This may lead to the errorneous result of RTS-on-send
>>>>>> being set even if only RTS-after-send is supported.
>>>>>>
>>>>>> Fix this by changing the implemented logic: First clear all unsupported
>>>>>> flags in the RS485 configuration, then adjust an invalid RTS setting by
>>>>>> taking into account which RTS mode is supported.
>>>>>>
>>>>>> Cc: [email protected]
>>>>>> Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
>>>>>> Signed-off-by: Lino Sanfilippo <[email protected]>
>>>>>> ---
>>>>>> drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++----------
>>>>>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>>>>>> index 697c36dc7ec8..f4feebf8200f 100644
>>>>>> --- a/drivers/tty/serial/serial_core.c
>>>>>> +++ b/drivers/tty/serial/serial_core.c
>>>>>> @@ -1370,19 +1370,27 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> + rs485->flags &= supported_flags;
>>>>>> +
>>>>>> /* Pick sane settings if the user hasn't */
>>>>>> - if ((supported_flags & (SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND)) &&
>>>>>> - !(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>>>>>> + if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
>>>>>> !(rs485->flags & SER_RS485_RTS_AFTER_SEND)) {
>>>>>> - dev_warn_ratelimited(port->dev,
>>>>>> - "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>>>>>> - port->name, port->line);
>>>>>> - rs485->flags |= SER_RS485_RTS_ON_SEND;
>>>>>> - rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>>>>>> - supported_flags |= SER_RS485_RTS_ON_SEND|SER_RS485_RTS_AFTER_SEND;
>>>>>> - }
>>>>>> + if (supported_flags & SER_RS485_RTS_ON_SEND) {
>>>>>> + rs485->flags |= SER_RS485_RTS_ON_SEND;
>>>>>> + rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>>>>>>
>>>>>> - rs485->flags &= supported_flags;
>>>>>> + dev_warn_ratelimited(port->dev,
>>>>>> + "%s (%d): invalid RTS setting, using RTS_ON_SEND instead\n",
>>>>>> + port->name, port->line);
>>>>>> + } else {
>>>>>> + rs485->flags |= SER_RS485_RTS_AFTER_SEND;
>>>>>> + rs485->flags &= ~SER_RS485_RTS_ON_SEND;
>>>>>
>>>>> So if neither of the flags is supported, what will happen? You might want
>>>>> add if after that else?
>>>>>
>>>>
>>>> I would consider this a bug in the driver, as at least one of both modes
>>>> has to be supported. If the driver does not have at least one of both flags
>>>> set in rs485_supported.flags we could print a warning though. Would you prefer that?
>>>
>>> 8250_exar.c needs to fixed then?
>> I was taking these as things one can
>>> "configure" even if when there's support only for a one of them there's
>>> not that much to configure. As there was neither in 8250_exar's code, I
>>> didn't add either flag.
>>
>>> But I suppose your interpretation of those flag makes more sense.
>>
>> IMHO this is consistent with what we have in uart_get_rs485_mode(). This function
>> ensures that we have at least one RTS mode set (with default to RTS_ON_SEND). So
>> concerning 8250_exar.c, I think it should be fixed (havent noticed the missing
>> RTS mode though until you mentioned it). Would you like to provide a fix for this
>> or shall I include one into the next version of this series?
>
> Just create that fix yourself thank you and include it into your series,
> I'm busy with other stuff currently.
>
>
Sure, will do.
BR,
Lino
Hello Lino,
On Sun, Oct 15, 2023 at 03:03:20PM +0200, Lino Sanfilippo wrote:
> Sorry Uwe, you gave valuable input for the former version of this series and I
> just noticed now that I forgot to Cc you for this version.
My mail setup works good enough that this series already landed in my
inbox without the explict Cc, but I'm currently doing too much other
stuff to find the time for an appropriate look here, sorry.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi,
On 16.10.23 12:38, Uwe Kleine-König wrote:
> Hello Lino,
>
> On Sun, Oct 15, 2023 at 03:03:20PM +0200, Lino Sanfilippo wrote:
>> Sorry Uwe, you gave valuable input for the former version of this series and I
>> just noticed now that I forgot to Cc you for this version.
>
> My mail setup works good enough that this series already landed in my
> inbox without the explict Cc, but I'm currently doing too much other
> stuff to find the time for an appropriate look here, sorry.
>
No problem, I can fully understand that.
BR,
Lino