* [PATCH v4 1/7] serial: Do not hold the port lock when setting rx-during-tx GPIO
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 2/7] serial: core: set missing supported flag for RX during TX GPIO Lino Sanfilippo
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
Both the imx and stm32 driver set the rx-during-tx GPIO in rs485_config().
Since this function 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 moving the GPIO setting outside of the port lock into
the serial core and thus making it a generic feature.
Since both setting the term and the rx-during-tx GPIO is done at the same
code place, move it into a common function.
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: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
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 | 15 +++++++++++----
drivers/tty/serial/stm32-usart.c | 5 +----
3 files changed, 12 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 d5ba6e90bd95..35e014f83465 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1391,14 +1391,21 @@ 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)
+/*
+ * Set optional RS485 GPIOs for bus termination and data reception during
+ * transmission. These GPIOs are controlled by the serial core independently
+ * from the UART driver.
+ */
+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)
@@ -1411,7 +1418,7 @@ static int uart_rs485_config(struct uart_port *port)
return 0;
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, NULL, rs485);
@@ -1455,7 +1462,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] 9+ messages in thread* [PATCH v4 2/7] serial: core: set missing supported flag for RX during TX GPIO
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 1/7] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 3/7] serial: core: fix sanitizing check for RTS settings Lino Sanfilippo
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
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 35e014f83465..ef9e9014bfab 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3632,6 +3632,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] 9+ messages in thread* [PATCH v4 3/7] serial: core: fix sanitizing check for RTS settings
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 1/7] serial: Do not hold the port lock when setting rx-during-tx GPIO Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 2/7] serial: core: set missing supported flag for RX during TX GPIO Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 4/7] serial: core: make sure RS485 cannot be enabled when it is not supported Lino Sanfilippo
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
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 ef9e9014bfab..f1d889f9fd6e 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] 9+ messages in thread* [PATCH v4 4/7] serial: core: make sure RS485 cannot be enabled when it is not supported
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
` (2 preceding siblings ...)
2023-10-18 17:48 ` [PATCH v4 3/7] serial: core: fix sanitizing check for RTS settings Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 5/7] serial: core, imx: do not set RS485 enabled if " Lino Sanfilippo
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
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: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
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 f1d889f9fd6e..49dd5e864719 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1443,6 +1443,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);
@@ -1460,7 +1463,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] 9+ messages in thread* [PATCH v4 5/7] serial: core, imx: do not set RS485 enabled if it is not supported
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
` (3 preceding siblings ...)
2023-10-18 17:48 ` [PATCH v4 4/7] serial: core: make sure RS485 cannot be enabled when it is not supported Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 6/7] serial: omap: do not override settings for RS485 support Lino Sanfilippo
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
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: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
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 49dd5e864719..c85275a573e3 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3586,6 +3586,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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v4 6/7] serial: omap: do not override settings for RS485 support
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
` (4 preceding siblings ...)
2023-10-18 17:48 ` [PATCH v4 5/7] serial: core, imx: do not set RS485 enabled if " Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-18 17:48 ` [PATCH v4 7/7] serial: 8250_exar: Set missing rs485_supported flag Lino Sanfilippo
2023-10-27 11:03 ` [PATCH v4 0/7] Fixes and improvements for RS485 Greg KH
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
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: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v4 7/7] serial: 8250_exar: Set missing rs485_supported flag
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
` (5 preceding siblings ...)
2023-10-18 17:48 ` [PATCH v4 6/7] serial: omap: do not override settings for RS485 support Lino Sanfilippo
@ 2023-10-18 17:48 ` Lino Sanfilippo
2023-10-27 11:03 ` [PATCH v4 0/7] Fixes and improvements for RS485 Greg KH
7 siblings, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2023-10-18 17:48 UTC (permalink / raw)
To: gregkh, jirislaby, ilpo.jarvinen
Cc: u.kleine-koenig, shawnguo, s.hauer, mcoquelin.stm32,
alexandre.torgue, cniedermaier, linux-kernel, linux-serial,
LinoSanfilippo, lukas, p.rosenberger, Lino Sanfilippo, stable
The UART supports an auto-RTS mode in which the RTS pin is automatically
activated during transmission. So mark this mode as being supported even
if RTS is not controlled by the driver but the UART.
Also the serial core expects now at least one of both modes rts-on-send or
rts-after-send to be supported. This is since during sanitization
unsupported flags are deleted from a RS485 configuration set by userspace.
However if the configuration ends up with both flags unset, the core prints
a warning since it considers such a configuration invalid (see
uart_sanitize_serial_rs485()).
Cc: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
drivers/tty/serial/8250/8250_exar.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
This patch is only required if "serial: core: fix sanitizing check for RTS
settings" is applied, which is also part of this series.
Therefore it lacks a "Fixes:" tag.
diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c
index 077c3ba3539e..8385be846840 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -446,7 +446,7 @@ static int generic_rs485_config(struct uart_port *port, struct ktermios *termios
}
static const struct serial_rs485 generic_rs485_supported = {
- .flags = SER_RS485_ENABLED,
+ .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
};
static const struct exar8250_platform exar8250_default_platform = {
@@ -490,7 +490,8 @@ static int iot2040_rs485_config(struct uart_port *port, struct ktermios *termios
}
static const struct serial_rs485 iot2040_rs485_supported = {
- .flags = SER_RS485_ENABLED | SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS,
+ .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND |
+ SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS,
};
static const struct property_entry iot2040_gpio_properties[] = {
--
2.40.1
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v4 0/7] Fixes and improvements for RS485
2023-10-18 17:48 [PATCH v4 0/7] Fixes and improvements for RS485 Lino Sanfilippo
` (6 preceding siblings ...)
2023-10-18 17:48 ` [PATCH v4 7/7] serial: 8250_exar: Set missing rs485_supported flag Lino Sanfilippo
@ 2023-10-27 11:03 ` Greg KH
7 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2023-10-27 11:03 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: jirislaby, ilpo.jarvinen, u.kleine-koenig, shawnguo, s.hauer,
mcoquelin.stm32, alexandre.torgue, cniedermaier, linux-kernel,
linux-serial, LinoSanfilippo, lukas, p.rosenberger
On Wed, Oct 18, 2023 at 07:48:33PM +0200, 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: set missing supported flag for RX during TX GPIO
> Patch 3: fix sanitizing check for RTS settings
> Patch 4: make sure RS485 is cannot be enabled when it is not supported
> Patch 5: imx: do not set RS485 enabled if it is not supported
> Patch 6: omap: do not override settings for rs485 support
> Patch 7: exar: set missing RS485 supported flag
>
> Changes in v4:
> - add comment for function uart_set_rs485_gpios after hint from Hugo
> - correct commit message as pointed out by Hugo
> - rephrase commit messages
> - add patch 7 after discussion with Ilpo
There's a lot of fuzz for this series against my current tree, so much
so I don't feel comfortable taking it right now. Can you resend it
after 6.7-rc1 is out and you have rebased it against that? If these
really are all bugfixes, we can still get them into 6.7-final then.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread