public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO
       [not found] <20230928221246.13689-1-LinoSanfilippo@gmx.de>
@ 2023-09-28 22:12 ` Lino Sanfilippo
  2023-09-29  5:50   ` Greg KH
  2023-09-28 22:12 ` [PATCH 3/6] serial: core: set missing supported flag for RX during TX GPIO Lino Sanfilippo
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-28 22:12 UTC (permalink / raw)
  To: gregkh, jirislaby
  Cc: shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo,
	LinoSanfilippo, lukas, p.rosenberger, stable

From: Lino Sanfilippo <l.sanfilippo@kunbus.com>

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.

Cc: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 3/6] serial: core: set missing supported flag for RX during TX GPIO
       [not found] <20230928221246.13689-1-LinoSanfilippo@gmx.de>
  2023-09-28 22:12 ` [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
@ 2023-09-28 22:12 ` Lino Sanfilippo
  2023-09-28 22:12 ` [PATCH 4/6] serial: core: fix sanitizing check for RTS settings Lino Sanfilippo
  2023-09-28 22:12 ` [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported Lino Sanfilippo
  3 siblings, 0 replies; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-28 22:12 UTC (permalink / raw)
  To: gregkh, jirislaby
  Cc: shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo,
	LinoSanfilippo, lukas, p.rosenberger, stable

From: Lino Sanfilippo <l.sanfilippo@kunbus.com>

If the RS485 feature RX-during-TX is supported by means of a GPIO set the
according supported flag. Otherwise setting this feature from userspace may
not be possible, since in uart_sanitize_serial_rs485() the passed RS485
configuration is matched against the supported features and unsupported
settings are thereby removed and thus take no effect.

Cc: stable@vger.kernel.org
Fixes: 163f080eb717 ("serial: core: Add option to output RS485 RX_DURING_TX state via GPIO")
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 ef0500be3553..697c36dc7ec8 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3622,6 +3622,8 @@ int uart_get_rs485_mode(struct uart_port *port)
 		port->rs485_rx_during_tx_gpio = NULL;
 		return dev_err_probe(dev, ret, "Cannot get rs485-rx-during-tx-gpios\n");
 	}
+	if (port->rs485_rx_during_tx_gpio)
+		port->rs485_supported.flags |= SER_RS485_RX_DURING_TX;
 
 	return 0;
 }
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 4/6] serial: core: fix sanitizing check for RTS settings
       [not found] <20230928221246.13689-1-LinoSanfilippo@gmx.de>
  2023-09-28 22:12 ` [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
  2023-09-28 22:12 ` [PATCH 3/6] serial: core: set missing supported flag for RX during TX GPIO Lino Sanfilippo
@ 2023-09-28 22:12 ` Lino Sanfilippo
  2023-09-28 22:12 ` [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported Lino Sanfilippo
  3 siblings, 0 replies; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-28 22:12 UTC (permalink / raw)
  To: gregkh, jirislaby
  Cc: shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo,
	LinoSanfilippo, lukas, p.rosenberger, stable

From: Lino Sanfilippo <l.sanfilippo@kunbus.com>

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: stable@vger.kernel.org
Fixes: be2e2cb1d281 ("serial: Sanitize rs485_struct")
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported
       [not found] <20230928221246.13689-1-LinoSanfilippo@gmx.de>
                   ` (2 preceding siblings ...)
  2023-09-28 22:12 ` [PATCH 4/6] serial: core: fix sanitizing check for RTS settings Lino Sanfilippo
@ 2023-09-28 22:12 ` Lino Sanfilippo
  2023-09-29 12:17   ` Hugo Villeneuve
  3 siblings, 1 reply; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-28 22:12 UTC (permalink / raw)
  To: gregkh, jirislaby
  Cc: shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo,
	LinoSanfilippo, lukas, p.rosenberger, stable

From: Lino Sanfilippo <l.sanfilippo@kunbus.com>

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.

Cc: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 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


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO
  2023-09-28 22:12 ` [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
@ 2023-09-29  5:50   ` Greg KH
  2023-09-29 12:21     ` Lino Sanfilippo
  0 siblings, 1 reply; 8+ messages in thread
From: Greg KH @ 2023-09-29  5:50 UTC (permalink / raw)
  To: Lino Sanfilippo
  Cc: jirislaby, shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo, lukas,
	p.rosenberger, stable

On Fri, Sep 29, 2023 at 12:12:41AM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> 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.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>

You cc: stable on many of these, but do not provide a "Fixes:" tag
showing just how far back they should go.  Can you do that so that we
have a hint as to what to do here?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported
  2023-09-28 22:12 ` [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported Lino Sanfilippo
@ 2023-09-29 12:17   ` Hugo Villeneuve
  2023-09-29 12:25     ` Lino Sanfilippo
  0 siblings, 1 reply; 8+ messages in thread
From: Hugo Villeneuve @ 2023-09-29 12:17 UTC (permalink / raw)
  To: Lino Sanfilippo
  Cc: gregkh, jirislaby, shawnguo, s.hauer, ilpo.jarvinen,
	mcoquelin.stm32, alexandre.torgue, linux-kernel, linux-serial,
	l.sanfilippo, lukas, p.rosenberger, stable

Hi,
remove superfluous "is" after RS485 in patch title.

Hugo.



On Fri, 29 Sep 2023 00:12:45 +0200
Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> 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.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  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
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO
  2023-09-29  5:50   ` Greg KH
@ 2023-09-29 12:21     ` Lino Sanfilippo
  0 siblings, 0 replies; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-29 12:21 UTC (permalink / raw)
  To: Greg KH
  Cc: jirislaby, shawnguo, s.hauer, ilpo.jarvinen, mcoquelin.stm32,
	alexandre.torgue, linux-kernel, linux-serial, l.sanfilippo, lukas,
	p.rosenberger, stable

Hi,

On 29.09.23 07:50, Greg KH wrote:
> On Fri, Sep 29, 2023 at 12:12:41AM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> 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.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>
> You cc: stable on many of these, but do not provide a "Fixes:" tag
> showing just how far back they should go.  Can you do that so that we
> have a hint as to what to do here?
>

Yes, will do so in the next version.

BR,
Lino

> thanks,
>
> greg k-h

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported
  2023-09-29 12:17   ` Hugo Villeneuve
@ 2023-09-29 12:25     ` Lino Sanfilippo
  0 siblings, 0 replies; 8+ messages in thread
From: Lino Sanfilippo @ 2023-09-29 12:25 UTC (permalink / raw)
  To: Hugo Villeneuve
  Cc: gregkh, jirislaby, shawnguo, s.hauer, ilpo.jarvinen,
	mcoquelin.stm32, alexandre.torgue, linux-kernel, linux-serial,
	l.sanfilippo, lukas, p.rosenberger, stable

Hi,

On 29.09.23 14:17, Hugo Villeneuve wrote:
> Hi,
> remove superfluous "is" after RS485 in patch title.
>
> Hugo.
>

Indeed, I will fix this, thanks!

BR,
Lino



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-09-29 12:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20230928221246.13689-1-LinoSanfilippo@gmx.de>
2023-09-28 22:12 ` [PATCH 1/6] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
2023-09-29  5:50   ` Greg KH
2023-09-29 12:21     ` Lino Sanfilippo
2023-09-28 22:12 ` [PATCH 3/6] serial: core: set missing supported flag for RX during TX GPIO Lino Sanfilippo
2023-09-28 22:12 ` [PATCH 4/6] serial: core: fix sanitizing check for RTS settings Lino Sanfilippo
2023-09-28 22:12 ` [PATCH 5/6] serial: core: make sure RS485 is cannot be enabled when it is not supported Lino Sanfilippo
2023-09-29 12:17   ` Hugo Villeneuve
2023-09-29 12:25     ` Lino Sanfilippo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox