From: Lino Sanfilippo <[email protected]>
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
Lino Sanfilippo (6):
serial: Do not hold the port lock when setting rx-during-tx GPIO
serial: amba-pl011: get rid of useless wrapper pl011_get_rs485_mode()
serial: core: set missing supported flag for RX during TX GPIO
serial: core: fix sanitizing check for RTS settings
serial: core: make sure RS485 is cannot be enabled when it is not
supported
serial: imx: do not set RS485 enabled if it is not supported
drivers/tty/serial/amba-pl011.c | 14 +---------
drivers/tty/serial/imx.c | 18 +++++--------
drivers/tty/serial/serial_core.c | 45 +++++++++++++++++++++-----------
drivers/tty/serial/stm32-usart.c | 5 +---
4 files changed, 38 insertions(+), 44 deletions(-)
base-commit: 9ed22ae6be817d7a3f5c15ca22cbc9d3963b481d
--
2.40.1
From: Lino Sanfilippo <[email protected]>
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: [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
From: Lino Sanfilippo <[email protected]>
If the imx driver cannot support RS485 it sets the UARTS rs485_supported
structure to NULL. But it still calls uart_get_rs485_mode() which may set
the RS485_ENABLED flag.
The flag however is evaluated by the serial core in uart_configure_port()
at port startup and thus may lead to an attempt to configure RS485 even if
it is not supported.
Avoid this by calling uart_get_rs485_mode() only if RS485 is actually
supported by the driver. Remove also a check for an error condition
that is not possible any more now.
Signed-off-by: Lino Sanfilippo <[email protected]>
---
drivers/tty/serial/imx.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index edb2ec6a5567..87689abc21bd 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2326,16 +2326,14 @@ static int imx_uart_probe(struct platform_device *pdev)
return ret;
}
- ret = uart_get_rs485_mode(&sport->port);
- if (ret) {
- clk_disable_unprepare(sport->clk_ipg);
- return ret;
+ if (sport->port.rs485_supported.flags & SER_RS485_ENABLED) {
+ ret = uart_get_rs485_mode(&sport->port);
+ if (ret) {
+ clk_disable_unprepare(sport->clk_ipg);
+ 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
--
2.40.1
On Fri, Sep 29, 2023 at 12:12:46AM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <[email protected]>
>
> If the imx driver cannot support RS485 it sets the UARTS rs485_supported
> structure to NULL. But it still calls uart_get_rs485_mode() which may set
> the RS485_ENABLED flag.
> The flag however is evaluated by the serial core in uart_configure_port()
I wonder if this is the code location where this problem should be
addressed. Or alternatively don't let uart_get_rs485_mode() set
RS485_ENABLED (and other flags) if rs485_supported doesn't suggest that
this works?
> [...]
>
> Signed-off-by: Lino Sanfilippo <[email protected]>
I don't know how picky Greg is here, but formally you missed to add an
S-o-b line for the sender of this patch (i.e. you with your gmx
address).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri, Sep 29, 2023 at 12:12:46AM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <[email protected]>
>
> If the imx driver cannot support RS485 it sets the UARTS rs485_supported
> structure to NULL. But it still calls uart_get_rs485_mode() which may set
> the RS485_ENABLED flag.
> The flag however is evaluated by the serial core in uart_configure_port()
> at port startup and thus may lead to an attempt to configure RS485 even if
> it is not supported.
>
> Avoid this by calling uart_get_rs485_mode() only if RS485 is actually
> supported by the driver. Remove also a check for an error condition
> that is not possible any more now.
>
> Signed-off-by: Lino Sanfilippo <[email protected]>
> ---
> drivers/tty/serial/imx.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
Why is this patch not marked for stable?
thanks,
greg k-h
On Fri, Sep 29, 2023 at 12:12:41AM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <[email protected]>
>
> 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: [email protected]
> Signed-off-by: Lino Sanfilippo <[email protected]>
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
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 <[email protected]>
>>
>> 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: [email protected]
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>
> 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
Hello Lino,
On Fri, Sep 29, 2023 at 03:46:52PM +0200, Lino Sanfilippo wrote:
> On 29.09.23 08:39, Uwe Kleine-K?nig wrote:
> > On Fri, Sep 29, 2023 at 12:12:46AM +0200, Lino Sanfilippo wrote:
> >> Signed-off-by: Lino Sanfilippo <[email protected]>
> >
> > I don't know how picky Greg is here, but formally you missed to add an
> > S-o-b line for the sender of this patch (i.e. you with your gmx
> > address).
> >
>
> Hm, until now there have never been complaints about this. Is this really an issue? Of
> course I can also S-o-b with my gmx address but adding two S-o-b's for the same person seems
> a bit odd to me...
The obvious and easy fix is of course to use the author address to send
the patches. :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On 29.09.23 07:51, Greg KH wrote:
> On Fri, Sep 29, 2023 at 12:12:46AM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <[email protected]>
>>
>> If the imx driver cannot support RS485 it sets the UARTS rs485_supported
>> structure to NULL. But it still calls uart_get_rs485_mode() which may set
>> the RS485_ENABLED flag.
>> The flag however is evaluated by the serial core in uart_configure_port()
>> at port startup and thus may lead to an attempt to configure RS485 even if
>> it is not supported.
>>
>> Avoid this by calling uart_get_rs485_mode() only if RS485 is actually
>> supported by the driver. Remove also a check for an error condition
>> that is not possible any more now.
>>
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>> ---
>> drivers/tty/serial/imx.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> Why is this patch not marked for stable?
>
Right, it should be, I will correct this, thanks!
Hi,
On 29.09.23 08:39, Uwe Kleine-König wrote:
> On Fri, Sep 29, 2023 at 12:12:46AM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <[email protected]>
>>
>> If the imx driver cannot support RS485 it sets the UARTS rs485_supported
>> structure to NULL. But it still calls uart_get_rs485_mode() which may set
>> the RS485_ENABLED flag.
>> The flag however is evaluated by the serial core in uart_configure_port()
>
> I wonder if this is the code location where this problem should be
> addressed. Or alternatively don't let uart_get_rs485_mode() set
> RS485_ENABLED (and other flags) if rs485_supported doesn't suggest that
> this works?
>
This is indeed the better solution. Especially since the check is then in the serial
core and all RS485 supporting drivers benefit from it. I will change this for v2, thanks!
>> [...]
>>
>> Signed-off-by: Lino Sanfilippo <[email protected]>
>
> I don't know how picky Greg is here, but formally you missed to add an
> S-o-b line for the sender of this patch (i.e. you with your gmx
> address).
>
Hm, until now there have never been complaints about this. Is this really an issue? Of
course I can also S-o-b with my gmx address but adding two S-o-b's for the same person seems
a bit odd to me...
BR,
Lino
> Best regards
> Uwe
>