[PATCH 0/8] Fixes and cleanup for RS485

[PATCH 0/8] Fixes and cleanup for RS485

[Lino Sanfilippo]

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

The following series includes cleanup and fixes around RS485 in the serial
core and uart drivers:

Patch 1: Only request the rs485 termination gpio if it is supported.
Patch 2: Set the rs485 termination GPIO in the serial core. This is needed
	 since if the gpio is only accessible in sleepable context. It also
	 is a further step to make the RS485 handling more generic.
Patch 3: Move sanitizing of RS485 delays into an own function. This is in 
	 preparation of patch 4.
Patch 4: Sanitize RS485 delays read from device tree.
Patch 5: Correct RS485 delays in binding documentation.
Patch 6: Remove redundant code in 8250_dwlib.
Patch 7: Remove redundant code in ar933x.
Patch 8: Remove redundant code in 8250-lpc18xx.

This patchset is based tty-testing.

Lino Sanfilippo (8):
  serial: core: only get RS485 termination gpio if supported
  serial: core, 8250: set RS485 termination gpio in serial core
  serial: core: move sanitizing of RS485 delays into own function
  serial: core: sanitize RS485 delays read from device tree
  dt_bindings: rs485: Correct delay values
  serial: 8250_dwlib: remove redundant sanity check for RS485 flags
  serial: ar933x: Remove redundant assignment in rs485_config
  serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

 .../devicetree/bindings/serial/rs485.yaml     |  4 +-
 drivers/tty/serial/8250/8250_dwlib.c          | 10 +--
 drivers/tty/serial/8250/8250_lpc18xx.c        |  6 +-
 drivers/tty/serial/8250/8250_port.c           |  3 -
 drivers/tty/serial/ar933x_uart.c              |  1 -
 drivers/tty/serial/serial_core.c              | 85 ++++++++++++-------
 6 files changed, 59 insertions(+), 50 deletions(-)


base-commit: df36f3e3fbb76d30d623a1623e31e3ce9c2fa750
-- 
2.36.1

[PATCH 0/8] Fixes and cleanup for RS485

[Lino Sanfilippo]

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

The following series includes cleanup and fixes around RS485 in the serial
core and uart drivers:

Patch 1: Only request the rs485 termination gpio if it is supported.
Patch 2: Set the rs485 termination GPIO in the serial core. This is needed
	 since if the gpio is only accessible in sleepable context. It also
	 is a further step to make the RS485 handling more generic.
Patch 3: Move sanitizing of RS485 delays into an own function. This is in 
	 preparation of patch 4.
Patch 4: Sanitize RS485 delays read from device tree.
Patch 5: Correct RS485 delays in binding documentation.
Patch 6: Remove redundant code in 8250_dwlib.
Patch 7: Remove redundant code in ar933x.
Patch 8: Remove redundant code in 8250-lpc18xx.

This patchset is based tty-testing.

Lino Sanfilippo (8):
  serial: core: only get RS485 termination gpio if supported
  serial: core, 8250: set RS485 termination gpio in serial core
  serial: core: move sanitizing of RS485 delays into own function
  serial: core: sanitize RS485 delays read from device tree
  dt_bindings: rs485: Correct delay values
  serial: 8250_dwlib: remove redundant sanity check for RS485 flags
  serial: ar933x: Remove redundant assignment in rs485_config
  serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

 .../devicetree/bindings/serial/rs485.yaml     |  4 +-
 drivers/tty/serial/8250/8250_dwlib.c          | 10 +--
 drivers/tty/serial/8250/8250_lpc18xx.c        |  6 +-
 drivers/tty/serial/8250/8250_port.c           |  3 -
 drivers/tty/serial/ar933x_uart.c              |  1 -
 drivers/tty/serial/serial_core.c              | 85 ++++++++++++-------
 6 files changed, 59 insertions(+), 50 deletions(-)


base-commit: df36f3e3fbb76d30d623a1623e31e3ce9c2fa750
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

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

In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
termination is supported by the driver.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 1368b0ef7d7f..015f4e1da647 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port)
 		rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
 	}
 
-	/*
-	 * Disabling termination by default is the safe choice:  Else if many
-	 * bus participants enable it, no communication is possible at all.
-	 * Works fine for short cables and users may enable for longer cables.
-	 */
-	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
-							GPIOD_OUT_LOW);
-	if (IS_ERR(port->rs485_term_gpio)) {
-		ret = PTR_ERR(port->rs485_term_gpio);
-		port->rs485_term_gpio = NULL;
-		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
+	if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) {
+		/*
+		 * Disabling termination by default is the safe choice:  Else if
+		 * many bus participants enable it, no communication is possible
+		 * at all. Works fine for short cables and users may enable for
+		 * longer cables.
+		 */
+		port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
+								GPIOD_OUT_LOW);
+		if (IS_ERR(port->rs485_term_gpio)) {
+			ret = PTR_ERR(port->rs485_term_gpio);
+			port->rs485_term_gpio = NULL;
+			return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
+		}
 	}
 
 	return 0;
-- 
2.36.1

[PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

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

In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
termination is supported by the driver.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 1368b0ef7d7f..015f4e1da647 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port)
 		rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
 	}
 
-	/*
-	 * Disabling termination by default is the safe choice:  Else if many
-	 * bus participants enable it, no communication is possible at all.
-	 * Works fine for short cables and users may enable for longer cables.
-	 */
-	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
-							GPIOD_OUT_LOW);
-	if (IS_ERR(port->rs485_term_gpio)) {
-		ret = PTR_ERR(port->rs485_term_gpio);
-		port->rs485_term_gpio = NULL;
-		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
+	if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) {
+		/*
+		 * Disabling termination by default is the safe choice:  Else if
+		 * many bus participants enable it, no communication is possible
+		 * at all. Works fine for short cables and users may enable for
+		 * longer cables.
+		 */
+		port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
+								GPIOD_OUT_LOW);
+		if (IS_ERR(port->rs485_term_gpio)) {
+			ret = PTR_ERR(port->rs485_term_gpio);
+			port->rs485_term_gpio = NULL;
+			return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
+		}
 	}
 
 	return 0;
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> termination is supported by the driver.

I'm not sure I got the usefulness of this change.
We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
they probably want to (opportunistically) have it.

The certain driver may or may not utilize this GPIO.

With your change it's possible to have a DTS where GPIO line defined in a
broken way and user won't ever know about it, if they are using platforms
without termination support.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> termination is supported by the driver.

I'm not sure I got the usefulness of this change.
We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
they probably want to (opportunistically) have it.

The certain driver may or may not utilize this GPIO.

With your change it's possible to have a DTS where GPIO line defined in a
broken way and user won't ever know about it, if they are using platforms
without termination support.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

Hi,

On 22.06.22 at 19:04, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
>> termination is supported by the driver.
>
> I'm not sure I got the usefulness of this change.
> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> they probably want to (opportunistically) have it>
>
> With your change it's possible to have a DTS where GPIO line defined in a
> broken way and user won't ever know about it, if they are using platforms
> without termination support.
>

This behavior is not introduced with this patch, also in the current code the driver
wont inform the user if it does not make use erroneous defined termination GPIO.

This patch at least prevents the driver from allocating and holding a GPIO descriptor across
the drivers lifetime that will never be used.

Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can
skip the check whether or not the termination GPIO is supported by the driver.



Regards,
Lino

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

Hi,

On 22.06.22 at 19:04, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
>> termination is supported by the driver.
>
> I'm not sure I got the usefulness of this change.
> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> they probably want to (opportunistically) have it>
>
> With your change it's possible to have a DTS where GPIO line defined in a
> broken way and user won't ever know about it, if they are using platforms
> without termination support.
>

This behavior is not introduced with this patch, also in the current code the driver
wont inform the user if it does not make use erroneous defined termination GPIO.

This patch at least prevents the driver from allocating and holding a GPIO descriptor across
the drivers lifetime that will never be used.

Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can
skip the check whether or not the termination GPIO is supported by the driver.



Regards,
Lino


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
> On 22.06.22 at 19:04, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> >> termination is supported by the driver.
> >
> > I'm not sure I got the usefulness of this change.
> > We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> > they probably want to (opportunistically) have it>
> >
> > With your change it's possible to have a DTS where GPIO line defined in a
> > broken way and user won't ever know about it, if they are using platforms
> > without termination support.
>
> This behavior is not introduced with this patch, also in the current code the driver
> wont inform the user if it does not make use erroneous defined termination GPIO.

It does. If a previously stale GPIO resource may have deferred a probe
and hence one may debug why the driver is not working, after this
change one may put a stale GPIO resource into DT/ACPI and have nothing
in the result. Meaning the change relaxes validation which I consider
is not good.

> This patch at least prevents the driver from allocating and holding a GPIO descriptor across
> the drivers lifetime that will never be used.

But it's not your issue, if DTS defines it, so the platform has an
idea about its usage.

> Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can
> skip the check whether or not the termination GPIO is supported by the driver.

That's fine.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
> On 22.06.22 at 19:04, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> >> termination is supported by the driver.
> >
> > I'm not sure I got the usefulness of this change.
> > We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> > they probably want to (opportunistically) have it>
> >
> > With your change it's possible to have a DTS where GPIO line defined in a
> > broken way and user won't ever know about it, if they are using platforms
> > without termination support.
>
> This behavior is not introduced with this patch, also in the current code the driver
> wont inform the user if it does not make use erroneous defined termination GPIO.

It does. If a previously stale GPIO resource may have deferred a probe
and hence one may debug why the driver is not working, after this
change one may put a stale GPIO resource into DT/ACPI and have nothing
in the result. Meaning the change relaxes validation which I consider
is not good.

> This patch at least prevents the driver from allocating and holding a GPIO descriptor across
> the drivers lifetime that will never be used.

But it's not your issue, if DTS defines it, so the platform has an
idea about its usage.

> Furthermore it simplifies the code in patch 2 when we want to set the GPIO, since we can
> skip the check whether or not the termination GPIO is supported by the driver.

That's fine.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

On 23.06.22 at 11:45, Andy Shevchenko wrote:
> On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
>> On 22.06.22 at 19:04, Andy Shevchenko wrote:
>>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
>>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>>
>>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
>>>> termination is supported by the driver.
>>>
>>> I'm not sure I got the usefulness of this change.
>>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
>>> they probably want to (opportunistically) have it>
>>>
>>> With your change it's possible to have a DTS where GPIO line defined in a
>>> broken way and user won't ever know about it, if they are using platforms
>>> without termination support.
>>
>> This behavior is not introduced with this patch, also in the current code the driver
>> wont inform the user if it does not make use erroneous defined termination GPIO.
>
> It does. If a previously stale GPIO resource may have deferred a probe
> and hence one may debug why the driver is not working, after this
> change one may put a stale GPIO resource into DT/ACPI and have nothing
> in the result. Meaning the change relaxes validation which I consider
> is not good.
>

Ok I see the point. So what about changing it to:

	if (port->rs485_term_gpio &&
	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
		dev_warn(port->dev,
			"%s (%d): RS485 termination gpio not supported by driver\n",
			port->name, port->line);
		devm_gpiod_put(dev, port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
	}

This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
RS485 settings.


Regards,
Lino

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

On 23.06.22 at 11:45, Andy Shevchenko wrote:
> On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
>> On 22.06.22 at 19:04, Andy Shevchenko wrote:
>>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
>>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>>
>>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
>>>> termination is supported by the driver.
>>>
>>> I'm not sure I got the usefulness of this change.
>>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
>>> they probably want to (opportunistically) have it>
>>>
>>> With your change it's possible to have a DTS where GPIO line defined in a
>>> broken way and user won't ever know about it, if they are using platforms
>>> without termination support.
>>
>> This behavior is not introduced with this patch, also in the current code the driver
>> wont inform the user if it does not make use erroneous defined termination GPIO.
>
> It does. If a previously stale GPIO resource may have deferred a probe
> and hence one may debug why the driver is not working, after this
> change one may put a stale GPIO resource into DT/ACPI and have nothing
> in the result. Meaning the change relaxes validation which I consider
> is not good.
>

Ok I see the point. So what about changing it to:

	if (port->rs485_term_gpio &&
	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
		dev_warn(port->dev,
			"%s (%d): RS485 termination gpio not supported by driver\n",
			port->name, port->line);
		devm_gpiod_put(dev, port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
	}

This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
RS485 settings.


Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 06:08:56PM +0200, Lino Sanfilippo wrote:
> On 23.06.22 at 11:45, Andy Shevchenko wrote:
> > On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
> >> On 22.06.22 at 19:04, Andy Shevchenko wrote:
> >>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> >>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>>>
> >>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> >>>> termination is supported by the driver.
> >>>
> >>> I'm not sure I got the usefulness of this change.
> >>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> >>> they probably want to (opportunistically) have it>
> >>>
> >>> With your change it's possible to have a DTS where GPIO line defined in a
> >>> broken way and user won't ever know about it, if they are using platforms
> >>> without termination support.
> >>
> >> This behavior is not introduced with this patch, also in the current code the driver
> >> wont inform the user if it does not make use erroneous defined termination GPIO.
> >
> > It does. If a previously stale GPIO resource may have deferred a probe
> > and hence one may debug why the driver is not working, after this
> > change one may put a stale GPIO resource into DT/ACPI and have nothing
> > in the result. Meaning the change relaxes validation which I consider
> > is not good.
> >
> 
> Ok I see the point. So what about changing it to:

You mean adding below after the existing code in the module?

> 	if (port->rs485_term_gpio &&
> 	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
> 		dev_warn(port->dev,
> 			"%s (%d): RS485 termination gpio not supported by driver\n",
> 			port->name, port->line);
> 		devm_gpiod_put(dev, port->rs485_term_gpio);
> 		port->rs485_term_gpio = NULL;
> 	}
> 
> This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
> RS485 settings.

Probably it's okay, but I dunno we have much on this to gain. Users may start
complaining of this (harmless) warning. I leave it to others to comment.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 06:08:56PM +0200, Lino Sanfilippo wrote:
> On 23.06.22 at 11:45, Andy Shevchenko wrote:
> > On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
> >> On 22.06.22 at 19:04, Andy Shevchenko wrote:
> >>> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> >>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>>>
> >>>> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> >>>> termination is supported by the driver.
> >>>
> >>> I'm not sure I got the usefulness of this change.
> >>> We request GPIO line as optional, so if one is defined it in the DT/ACPI, then
> >>> they probably want to (opportunistically) have it>
> >>>
> >>> With your change it's possible to have a DTS where GPIO line defined in a
> >>> broken way and user won't ever know about it, if they are using platforms
> >>> without termination support.
> >>
> >> This behavior is not introduced with this patch, also in the current code the driver
> >> wont inform the user if it does not make use erroneous defined termination GPIO.
> >
> > It does. If a previously stale GPIO resource may have deferred a probe
> > and hence one may debug why the driver is not working, after this
> > change one may put a stale GPIO resource into DT/ACPI and have nothing
> > in the result. Meaning the change relaxes validation which I consider
> > is not good.
> >
> 
> Ok I see the point. So what about changing it to:

You mean adding below after the existing code in the module?

> 	if (port->rs485_term_gpio &&
> 	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
> 		dev_warn(port->dev,
> 			"%s (%d): RS485 termination gpio not supported by driver\n",
> 			port->name, port->line);
> 		devm_gpiod_put(dev, port->rs485_term_gpio);
> 		port->rs485_term_gpio = NULL;
> 	}
> 
> This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
> RS485 settings.

Probably it's okay, but I dunno we have much on this to gain. Users may start
complaining of this (harmless) warning. I leave it to others to comment.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

On 23.06.22 at 18:32, Andy Shevchenko wrote:

>>
>> Ok I see the point. So what about changing it to:
>
> You mean adding below after the existing code in the module?

Right, to be more precise between getting the gpio and the error check:


	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
							GPIOD_OUT_LOW);

	if (port->rs485_term_gpio &&
	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
		dev_warn(port->dev,
			"%s (%d): RS485 termination gpio not supported by driver\n",
			port->name, port->line);
		devm_gpiod_put(dev, port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
	}

	if (IS_ERR(port->rs485_term_gpio)) {
		ret = PTR_ERR(port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
	}

Regards,
Lino

>
>> 	if (port->rs485_term_gpio &&
>> 	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
>> 		dev_warn(port->dev,
>> 			"%s (%d): RS485 termination gpio not supported by driver\n",
>> 			port->name, port->line);
>> 		devm_gpiod_put(dev, port->rs485_term_gpio);
>> 		port->rs485_term_gpio = NULL;
>> 	}
>>
>> This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
>> RS485 settings.
>
> Probably it's okay, but I dunno we have much on this to gain. Users may start
> complaining of this (harmless) warning. I leave it to others to comment.
>

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

On 23.06.22 at 18:32, Andy Shevchenko wrote:

>>
>> Ok I see the point. So what about changing it to:
>
> You mean adding below after the existing code in the module?

Right, to be more precise between getting the gpio and the error check:


	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
							GPIOD_OUT_LOW);

	if (port->rs485_term_gpio &&
	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
		dev_warn(port->dev,
			"%s (%d): RS485 termination gpio not supported by driver\n",
			port->name, port->line);
		devm_gpiod_put(dev, port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
	}

	if (IS_ERR(port->rs485_term_gpio)) {
		ret = PTR_ERR(port->rs485_term_gpio);
		port->rs485_term_gpio = NULL;
		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
	}

Regards,
Lino

>
>> 	if (port->rs485_term_gpio &&
>> 	    !(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
>> 		dev_warn(port->dev,
>> 			"%s (%d): RS485 termination gpio not supported by driver\n",
>> 			port->name, port->line);
>> 		devm_gpiod_put(dev, port->rs485_term_gpio);
>> 		port->rs485_term_gpio = NULL;
>> 	}
>>
>> This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
>> RS485 settings.
>
> Probably it's okay, but I dunno we have much on this to gain. Users may start
> complaining of this (harmless) warning. I leave it to others to comment.
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lukas Wunner]

On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> termination is supported by the driver.
[...]
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port)
>  		rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
>  	}
>  
> -	/*
> -	 * Disabling termination by default is the safe choice:  Else if many
> -	 * bus participants enable it, no communication is possible at all.
> -	 * Works fine for short cables and users may enable for longer cables.
> -	 */
> -	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
> -							GPIOD_OUT_LOW);
> -	if (IS_ERR(port->rs485_term_gpio)) {
> -		ret = PTR_ERR(port->rs485_term_gpio);
> -		port->rs485_term_gpio = NULL;
> -		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
> +	if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) {

So I think linux-next commit be2e2cb1d281 ("serial: Sanitize rs485_struct")
contains a mistake in that it forces drivers to set SER_RS485_TERMINATE_BUS
in their rs485_supported->flags to allow enabling bus termination.

That's wrong because *every* rs485-capable driver can enable bus
termination if a GPIO has been defined for that in the DT.

In fact, another commit which was applied as part of the same series,
ebe2cf736a04 ("serial: pl011: Fill in rs485_supported") does not set
SER_RS485_TERMINATE_BUS in amba-pl011.c's flags and thus forbids the
driver from enabling bus termination, even though we know there are
products out there which support bus termination on the pl011 through
a GPIO (Revolution Pi RevPi Compact, Revpi Flat).

I think what you want to do is amend uart_get_rs485_mode() to set
SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO
was found in the DT.  Instead of the change proposed above.

Thanks,

Lukas

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Ilpo Järvinen]

On Sat, 25 Jun 2022, Lukas Wunner wrote:

> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> > In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> > termination is supported by the driver.
> [...]
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port)
> >  		rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
> >  	}
> >  
> > -	/*
> > -	 * Disabling termination by default is the safe choice:  Else if many
> > -	 * bus participants enable it, no communication is possible at all.
> > -	 * Works fine for short cables and users may enable for longer cables.
> > -	 */
> > -	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
> > -							GPIOD_OUT_LOW);
> > -	if (IS_ERR(port->rs485_term_gpio)) {
> > -		ret = PTR_ERR(port->rs485_term_gpio);
> > -		port->rs485_term_gpio = NULL;
> > -		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
> > +	if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) {
> 
> So I think linux-next commit be2e2cb1d281 ("serial: Sanitize rs485_struct")
> contains a mistake in that it forces drivers to set SER_RS485_TERMINATE_BUS
> in their rs485_supported->flags to allow enabling bus termination.
> 
> That's wrong because *every* rs485-capable driver can enable bus
> termination if a GPIO has been defined for that in the DT.

Do you mean every em485 using driver? Otherwise I don't see this "forces 
drivers to set" happening anywhere in the code?

You're partially right because there are other bugs in this area such 
as the one you propose a fix below. While I was making the sanitization 
series, I entirely missed some parts related to termination because 
SER_RS485_TERMINATE_BUS is seemingly not set/handled correctly by the 
core.

Another thing that looks a bug is that on subsequent call to TIOCSRS485, 
w/o SER_RS485_TERMINATE_BUS nothing happens (for non-em485 driver, that 
is)? It seems to be taken care by 2/8 of this series though, I think. But 
it should be properly marked as Fixes: ... in that case although nobody 
has complained about it so likely not a huge issue to anyone.

> In fact, another commit which was applied as part of the same series,
> ebe2cf736a04 ("serial: pl011: Fill in rs485_supported") does not set
> SER_RS485_TERMINATE_BUS in amba-pl011.c's flags and thus forbids the
> driver from enabling bus termination, even though we know there are
> products out there which support bus termination on the pl011 through
> a GPIO (Revolution Pi RevPi Compact, Revpi Flat).
>
> I think what you want to do is amend uart_get_rs485_mode() to set
> SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO
> was found in the DT.  Instead of the change proposed above.

That seems appropriate (and is a fix).

What makes it a bit complicated though is that it's a pointer currently
and what it points to is shared per driver (besides being const):
	const struct serial_rs485       *rs485_supported;
While it could be embedded into uart_port, there's the .padding which we 
might not want to bloat uart_port with. Perhaps create non-uapi struct 
kserial_rs485 w/o .padding and add static_assert()s to ensure the 
layout is identical to serial_rs485?


-- 
 i.

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Ilpo Järvinen]

On Sat, 25 Jun 2022, Lukas Wunner wrote:

> On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:
> > In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus
> > termination is supported by the driver.
> [...]
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -3384,17 +3384,20 @@ int uart_get_rs485_mode(struct uart_port *port)
> >  		rs485conf->flags |= SER_RS485_RTS_AFTER_SEND;
> >  	}
> >  
> > -	/*
> > -	 * Disabling termination by default is the safe choice:  Else if many
> > -	 * bus participants enable it, no communication is possible at all.
> > -	 * Works fine for short cables and users may enable for longer cables.
> > -	 */
> > -	port->rs485_term_gpio = devm_gpiod_get_optional(dev, "rs485-term",
> > -							GPIOD_OUT_LOW);
> > -	if (IS_ERR(port->rs485_term_gpio)) {
> > -		ret = PTR_ERR(port->rs485_term_gpio);
> > -		port->rs485_term_gpio = NULL;
> > -		return dev_err_probe(dev, ret, "Cannot get rs485-term-gpios\n");
> > +	if (port->rs485_supported->flags & SER_RS485_TERMINATE_BUS) {
> 
> So I think linux-next commit be2e2cb1d281 ("serial: Sanitize rs485_struct")
> contains a mistake in that it forces drivers to set SER_RS485_TERMINATE_BUS
> in their rs485_supported->flags to allow enabling bus termination.
> 
> That's wrong because *every* rs485-capable driver can enable bus
> termination if a GPIO has been defined for that in the DT.

Do you mean every em485 using driver? Otherwise I don't see this "forces 
drivers to set" happening anywhere in the code?

You're partially right because there are other bugs in this area such 
as the one you propose a fix below. While I was making the sanitization 
series, I entirely missed some parts related to termination because 
SER_RS485_TERMINATE_BUS is seemingly not set/handled correctly by the 
core.

Another thing that looks a bug is that on subsequent call to TIOCSRS485, 
w/o SER_RS485_TERMINATE_BUS nothing happens (for non-em485 driver, that 
is)? It seems to be taken care by 2/8 of this series though, I think. But 
it should be properly marked as Fixes: ... in that case although nobody 
has complained about it so likely not a huge issue to anyone.

> In fact, another commit which was applied as part of the same series,
> ebe2cf736a04 ("serial: pl011: Fill in rs485_supported") does not set
> SER_RS485_TERMINATE_BUS in amba-pl011.c's flags and thus forbids the
> driver from enabling bus termination, even though we know there are
> products out there which support bus termination on the pl011 through
> a GPIO (Revolution Pi RevPi Compact, Revpi Flat).
>
> I think what you want to do is amend uart_get_rs485_mode() to set
> SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO
> was found in the DT.  Instead of the change proposed above.

That seems appropriate (and is a fix).

What makes it a bit complicated though is that it's a pointer currently
and what it points to is shared per driver (besides being const):
	const struct serial_rs485       *rs485_supported;
While it could be embedded into uart_port, there's the .padding which we 
might not want to bloat uart_port with. Perhaps create non-uapi struct 
kserial_rs485 w/o .padding and add static_assert()s to ensure the 
layout is identical to serial_rs485?


-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

Hi,

On 27.06.22 11:05, Ilpo Järvinen wrote:
> On Sat, 25 Jun 2022, Lukas Wunner wrote:

>>
>> I think what you want to do is amend uart_get_rs485_mode() to set
>> SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO
>> was found in the DT.  Instead of the change proposed above.

Agreed.

>
> That seems appropriate (and is a fix).
>
> What makes it a bit complicated though is that it's a pointer currently
> and what it points to is shared per driver (besides being const):
> 	const struct serial_rs485       *rs485_supported;
> While it could be embedded into uart_port, there's the .padding which we
> might not want to bloat uart_port with. Perhaps create non-uapi struct
> kserial_rs485 w/o .padding and add static_assert()s to ensure the
> layout is identical to serial_rs485?
>
>

This seems to be indeed the cleanest solution.

Regards,
Lino

Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported

[Lino Sanfilippo]

Hi,

On 27.06.22 11:05, Ilpo Järvinen wrote:
> On Sat, 25 Jun 2022, Lukas Wunner wrote:

>>
>> I think what you want to do is amend uart_get_rs485_mode() to set
>> SER_RS485_TERMINATE_BUS in port->rs485_supported_flags if a GPIO
>> was found in the DT.  Instead of the change proposed above.

Agreed.

>
> That seems appropriate (and is a fix).
>
> What makes it a bit complicated though is that it's a pointer currently
> and what it points to is shared per driver (besides being const):
> 	const struct serial_rs485       *rs485_supported;
> While it could be embedded into uart_port, there's the .padding which we
> might not want to bloat uart_port with. Perhaps create non-uapi struct
> kserial_rs485 w/o .padding and add static_assert()s to ensure the
> layout is identical to serial_rs485?
>
>

This seems to be indeed the cleanest solution.

Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

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

In serial8250_em485_config() the termination GPIO is set with the uart_port
spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
since the concerning GPIO expander is connected via SPI or I2C).

Fix this by setting the termination line outside of the uart_port spinlock
in the serial core.

This also makes setting the termination GPIO generic for all uart drivers.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_port.c |  3 ---
 drivers/tty/serial/serial_core.c    | 12 ++++++++++++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3e3d784aa628..5245c179cc51 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -675,9 +675,6 @@ int serial8250_em485_config(struct uart_port *port, struct serial_rs485 *rs485)
 		rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
 	}
 
-	gpiod_set_value(port->rs485_term_gpio,
-			rs485->flags & SER_RS485_TERMINATE_BUS);
-
 	/*
 	 * Both serial8250_em485_init() and serial8250_em485_destroy()
 	 * are idempotent.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 015f4e1da647..b387376e6fa2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1352,12 +1352,23 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
 	memset(rs485->padding, 0, sizeof(rs485->padding));
 }
 
+static void uart_set_rs485_termination(struct uart_port *port,
+				       const struct serial_rs485 *rs485)
+{
+	if (!port->rs485_term_gpio || !(rs485->flags & SER_RS485_ENABLED))
+		return;
+
+	gpiod_set_value_cansleep(port->rs485_term_gpio,
+				 !!(rs485->flags & SER_RS485_TERMINATE_BUS));
+}
+
 int uart_rs485_config(struct uart_port *port)
 {
 	struct serial_rs485 *rs485 = &port->rs485;
 	int ret;
 
 	uart_sanitize_serial_rs485(port, rs485);
+	uart_set_rs485_termination(port, rs485);
 
 	ret = port->rs485_config(port, rs485);
 	if (ret)
@@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
 	if (ret)
 		return ret;
 	uart_sanitize_serial_rs485(port, &rs485);
+	uart_set_rs485_termination(port, &rs485);
 
 	spin_lock_irqsave(&port->lock, flags);
 	ret = port->rs485_config(port, &rs485);
-- 
2.36.1

[PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

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

In serial8250_em485_config() the termination GPIO is set with the uart_port
spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
since the concerning GPIO expander is connected via SPI or I2C).

Fix this by setting the termination line outside of the uart_port spinlock
in the serial core.

This also makes setting the termination GPIO generic for all uart drivers.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_port.c |  3 ---
 drivers/tty/serial/serial_core.c    | 12 ++++++++++++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3e3d784aa628..5245c179cc51 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -675,9 +675,6 @@ int serial8250_em485_config(struct uart_port *port, struct serial_rs485 *rs485)
 		rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
 	}
 
-	gpiod_set_value(port->rs485_term_gpio,
-			rs485->flags & SER_RS485_TERMINATE_BUS);
-
 	/*
 	 * Both serial8250_em485_init() and serial8250_em485_destroy()
 	 * are idempotent.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 015f4e1da647..b387376e6fa2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1352,12 +1352,23 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
 	memset(rs485->padding, 0, sizeof(rs485->padding));
 }
 
+static void uart_set_rs485_termination(struct uart_port *port,
+				       const struct serial_rs485 *rs485)
+{
+	if (!port->rs485_term_gpio || !(rs485->flags & SER_RS485_ENABLED))
+		return;
+
+	gpiod_set_value_cansleep(port->rs485_term_gpio,
+				 !!(rs485->flags & SER_RS485_TERMINATE_BUS));
+}
+
 int uart_rs485_config(struct uart_port *port)
 {
 	struct serial_rs485 *rs485 = &port->rs485;
 	int ret;
 
 	uart_sanitize_serial_rs485(port, rs485);
+	uart_set_rs485_termination(port, rs485);
 
 	ret = port->rs485_config(port, rs485);
 	if (ret)
@@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
 	if (ret)
 		return ret;
 	uart_sanitize_serial_rs485(port, &rs485);
+	uart_set_rs485_termination(port, &rs485);
 
 	spin_lock_irqsave(&port->lock, flags);
 	ret = port->rs485_config(port, &rs485);
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In serial8250_em485_config() the termination GPIO is set with the uart_port
> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> since the concerning GPIO expander is connected via SPI or I2C).
> 
> Fix this by setting the termination line outside of the uart_port spinlock
> in the serial core.

This doesn't describe that this patch is actually changing GPIO to support
sleep mode. So, it doesn't fix anything. Please rephrase the commit message
accordingly.

> This also makes setting the termination GPIO generic for all uart drivers.

UART

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In serial8250_em485_config() the termination GPIO is set with the uart_port
> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> since the concerning GPIO expander is connected via SPI or I2C).
> 
> Fix this by setting the termination line outside of the uart_port spinlock
> in the serial core.

This doesn't describe that this patch is actually changing GPIO to support
sleep mode. So, it doesn't fix anything. Please rephrase the commit message
accordingly.

> This also makes setting the termination GPIO generic for all uart drivers.

UART

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

On 22.06.22 at 19:06, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In serial8250_em485_config() the termination GPIO is set with the uart_port
>> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
>> since the concerning GPIO expander is connected via SPI or I2C).
>>
>> Fix this by setting the termination line outside of the uart_port spinlock
>> in the serial core.
>
> This doesn't describe that this patch is actually changing GPIO to support
> sleep mode. So, it doesn't fix anything. Please rephrase the commit message
> accordingly.

Good point, I will adjust the commit message in the next version.

>> This also makes setting the termination GPIO generic for all uart drivers.
>
> UART
>

Right, upper letters should be used.

Thanks a lot for the review!

Regards,
Lino

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

On 22.06.22 at 19:06, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In serial8250_em485_config() the termination GPIO is set with the uart_port
>> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
>> since the concerning GPIO expander is connected via SPI or I2C).
>>
>> Fix this by setting the termination line outside of the uart_port spinlock
>> in the serial core.
>
> This doesn't describe that this patch is actually changing GPIO to support
> sleep mode. So, it doesn't fix anything. Please rephrase the commit message
> accordingly.

Good point, I will adjust the commit message in the next version.

>> This also makes setting the termination GPIO generic for all uart drivers.
>
> UART
>

Right, upper letters should be used.

Thanks a lot for the review!

Regards,
Lino



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In serial8250_em485_config() the termination GPIO is set with the uart_port
> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> since the concerning GPIO expander is connected via SPI or I2C).
> 
> Fix this by setting the termination line outside of the uart_port spinlock
> in the serial core.
> 
> This also makes setting the termination GPIO generic for all uart drivers.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/8250/8250_port.c |  3 ---
>  drivers/tty/serial/serial_core.c    | 12 ++++++++++++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 3e3d784aa628..5245c179cc51 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -675,9 +675,6 @@ int serial8250_em485_config(struct uart_port *port, struct serial_rs485 *rs485)
>  		rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>  	}
>  
> -	gpiod_set_value(port->rs485_term_gpio,
> -			rs485->flags & SER_RS485_TERMINATE_BUS);
> -
>  	/*
>  	 * Both serial8250_em485_init() and serial8250_em485_destroy()
>  	 * are idempotent.
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 015f4e1da647..b387376e6fa2 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1352,12 +1352,23 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>  	memset(rs485->padding, 0, sizeof(rs485->padding));
>  }
>  
> +static void uart_set_rs485_termination(struct uart_port *port,
> +				       const struct serial_rs485 *rs485)
> +{
> +	if (!port->rs485_term_gpio || !(rs485->flags & SER_RS485_ENABLED))
> +		return;
> +
> +	gpiod_set_value_cansleep(port->rs485_term_gpio,
> +				 !!(rs485->flags & SER_RS485_TERMINATE_BUS));
> +}
> +
>  int uart_rs485_config(struct uart_port *port)
>  {
>  	struct serial_rs485 *rs485 = &port->rs485;
>  	int ret;
>  
>  	uart_sanitize_serial_rs485(port, rs485);
> +	uart_set_rs485_termination(port, rs485);
>  
>  	ret = port->rs485_config(port, rs485);
>  	if (ret)
> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>  	if (ret)
>  		return ret;
>  	uart_sanitize_serial_rs485(port, &rs485);
> +	uart_set_rs485_termination(port, &rs485);
>  
>  	spin_lock_irqsave(&port->lock, flags);
>  	ret = port->rs485_config(port, &rs485);

When port->rs485_config(port, &rs485) returns non-zero, the input got 
partially applied?


-- 
 i.

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In serial8250_em485_config() the termination GPIO is set with the uart_port
> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> since the concerning GPIO expander is connected via SPI or I2C).
> 
> Fix this by setting the termination line outside of the uart_port spinlock
> in the serial core.
> 
> This also makes setting the termination GPIO generic for all uart drivers.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/8250/8250_port.c |  3 ---
>  drivers/tty/serial/serial_core.c    | 12 ++++++++++++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index 3e3d784aa628..5245c179cc51 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -675,9 +675,6 @@ int serial8250_em485_config(struct uart_port *port, struct serial_rs485 *rs485)
>  		rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
>  	}
>  
> -	gpiod_set_value(port->rs485_term_gpio,
> -			rs485->flags & SER_RS485_TERMINATE_BUS);
> -
>  	/*
>  	 * Both serial8250_em485_init() and serial8250_em485_destroy()
>  	 * are idempotent.
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 015f4e1da647..b387376e6fa2 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1352,12 +1352,23 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
>  	memset(rs485->padding, 0, sizeof(rs485->padding));
>  }
>  
> +static void uart_set_rs485_termination(struct uart_port *port,
> +				       const struct serial_rs485 *rs485)
> +{
> +	if (!port->rs485_term_gpio || !(rs485->flags & SER_RS485_ENABLED))
> +		return;
> +
> +	gpiod_set_value_cansleep(port->rs485_term_gpio,
> +				 !!(rs485->flags & SER_RS485_TERMINATE_BUS));
> +}
> +
>  int uart_rs485_config(struct uart_port *port)
>  {
>  	struct serial_rs485 *rs485 = &port->rs485;
>  	int ret;
>  
>  	uart_sanitize_serial_rs485(port, rs485);
> +	uart_set_rs485_termination(port, rs485);
>  
>  	ret = port->rs485_config(port, rs485);
>  	if (ret)
> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>  	if (ret)
>  		return ret;
>  	uart_sanitize_serial_rs485(port, &rs485);
> +	uart_set_rs485_termination(port, &rs485);
>  
>  	spin_lock_irqsave(&port->lock, flags);
>  	ret = port->rs485_config(port, &rs485);

When port->rs485_config(port, &rs485) returns non-zero, the input got 
partially applied?


-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

Hi,

On 25.06.22 at 12:40, Ilpo Järvinen wrote:
>> +
>>  int uart_rs485_config(struct uart_port *port)
>>  {
>>  	struct serial_rs485 *rs485 = &port->rs485;
>>  	int ret;
>>
>>  	uart_sanitize_serial_rs485(port, rs485);
>> +	uart_set_rs485_termination(port, rs485);
>>
>>  	ret = port->rs485_config(port, rs485);
>>  	if (ret)
>> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>>  	if (ret)
>>  		return ret;
>>  	uart_sanitize_serial_rs485(port, &rs485);
>> +	uart_set_rs485_termination(port, &rs485);
>>
>>  	spin_lock_irqsave(&port->lock, flags);
>>  	ret = port->rs485_config(port, &rs485);
>
> When port->rs485_config(port, &rs485) returns non-zero, the input got
> partially applied?
>
>
The thing is we dont know what the state of the termination GPIO (asserted or deasserted)
was before we set it and port->rs485_config() failed, so we cannot restore it.
We could read the GPIO before we change it but AFAIK this is unsafe since it is an output
pin. Maybe add a boolean variable "rs485_termination_gpio_asserted" to uart_port to track the
current state?


Regards,
Lino

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

Hi,

On 25.06.22 at 12:40, Ilpo Järvinen wrote:
>> +
>>  int uart_rs485_config(struct uart_port *port)
>>  {
>>  	struct serial_rs485 *rs485 = &port->rs485;
>>  	int ret;
>>
>>  	uart_sanitize_serial_rs485(port, rs485);
>> +	uart_set_rs485_termination(port, rs485);
>>
>>  	ret = port->rs485_config(port, rs485);
>>  	if (ret)
>> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>>  	if (ret)
>>  		return ret;
>>  	uart_sanitize_serial_rs485(port, &rs485);
>> +	uart_set_rs485_termination(port, &rs485);
>>
>>  	spin_lock_irqsave(&port->lock, flags);
>>  	ret = port->rs485_config(port, &rs485);
>
> When port->rs485_config(port, &rs485) returns non-zero, the input got
> partially applied?
>
>
The thing is we dont know what the state of the termination GPIO (asserted or deasserted)
was before we set it and port->rs485_config() failed, so we cannot restore it.
We could read the GPIO before we change it but AFAIK this is unsafe since it is an output
pin. Maybe add a boolean variable "rs485_termination_gpio_asserted" to uart_port to track the
current state?


Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lukas Wunner]

On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In serial8250_em485_config() the termination GPIO is set with the uart_port
> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> since the concerning GPIO expander is connected via SPI or I2C).
> 
> Fix this by setting the termination line outside of the uart_port spinlock
> in the serial core.
[...]
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>  	if (ret)
>  		return ret;
>  	uart_sanitize_serial_rs485(port, &rs485);
> +	uart_set_rs485_termination(port, &rs485);
>  
>  	spin_lock_irqsave(&port->lock, flags);
>  	ret = port->rs485_config(port, &rs485);

That's one way to solve the issue.  Another would be to push
acquisition of the port spinlock down into drivers.

I think in most drivers we don't need to take the port spinlock at all
or only for a few specific register accesses.  So taking the lock here
in the midlayer is likely unwarranted.  However, changing that requires
going through every single driver's ->rs485_config() callback and
checking whether it needs the lock or not.  That's painful, but
unavoidable in the long run.  This patch just kicks the can down the road...

Thanks,

Lukas

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

On 25.06.22 at 21:58, Lukas Wunner wrote:
> On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In serial8250_em485_config() the termination GPIO is set with the uart_port
>> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
>> since the concerning GPIO expander is connected via SPI or I2C).
>>
>> Fix this by setting the termination line outside of the uart_port spinlock
>> in the serial core.
> [...]
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>>  	if (ret)
>>  		return ret;
>>  	uart_sanitize_serial_rs485(port, &rs485);
>> +	uart_set_rs485_termination(port, &rs485);
>>
>>  	spin_lock_irqsave(&port->lock, flags);
>>  	ret = port->rs485_config(port, &rs485);
>
> That's one way to solve the issue.  Another would be to push
> acquisition of the port spinlock down into drivers.
>
> I think in most drivers we don't need to take the port spinlock at all
> or only for a few specific register accesses.  So taking the lock here
> in the midlayer is likely unwarranted.  However, changing that requires
> going through every single driver's ->rs485_config() callback and
> checking whether it needs the lock or not.

As a first step its sufficient to take the lock in each drivers rs485_config()
function and remove it from uart_set_rs485_config(). Then after time sort out
the drivers that dont require the lock and remove it from their function.

However the point of this patch was also to generalize the handling of the
termination GPIO, so I would still see this placed in uart_set_rs485_config().

Regards,
Lino

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Lino Sanfilippo]

On 25.06.22 at 21:58, Lukas Wunner wrote:
> On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In serial8250_em485_config() the termination GPIO is set with the uart_port
>> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
>> since the concerning GPIO expander is connected via SPI or I2C).
>>
>> Fix this by setting the termination line outside of the uart_port spinlock
>> in the serial core.
> [...]
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
>>  	if (ret)
>>  		return ret;
>>  	uart_sanitize_serial_rs485(port, &rs485);
>> +	uart_set_rs485_termination(port, &rs485);
>>
>>  	spin_lock_irqsave(&port->lock, flags);
>>  	ret = port->rs485_config(port, &rs485);
>
> That's one way to solve the issue.  Another would be to push
> acquisition of the port spinlock down into drivers.
>
> I think in most drivers we don't need to take the port spinlock at all
> or only for a few specific register accesses.  So taking the lock here
> in the midlayer is likely unwarranted.  However, changing that requires
> going through every single driver's ->rs485_config() callback and
> checking whether it needs the lock or not.

As a first step its sufficient to take the lock in each drivers rs485_config()
function and remove it from uart_set_rs485_config(). Then after time sort out
the drivers that dont require the lock and remove it from their function.

However the point of this patch was also to generalize the handling of the
termination GPIO, so I would still see this placed in uart_set_rs485_config().

Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Ilpo Järvinen]

On Sun, 26 Jun 2022, Lino Sanfilippo wrote:

> On 25.06.22 at 21:58, Lukas Wunner wrote:
> > On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In serial8250_em485_config() the termination GPIO is set with the uart_port
> >> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> >> since the concerning GPIO expander is connected via SPI or I2C).
> >>
> >> Fix this by setting the termination line outside of the uart_port spinlock
> >> in the serial core.
> > [...]
> >> --- a/drivers/tty/serial/serial_core.c
> >> +++ b/drivers/tty/serial/serial_core.c
> >> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
> >>  	if (ret)
> >>  		return ret;
> >>  	uart_sanitize_serial_rs485(port, &rs485);
> >> +	uart_set_rs485_termination(port, &rs485);
> >>
> >>  	spin_lock_irqsave(&port->lock, flags);
> >>  	ret = port->rs485_config(port, &rs485);
> >
> > That's one way to solve the issue.  Another would be to push
> > acquisition of the port spinlock down into drivers.
> >
> > I think in most drivers we don't need to take the port spinlock at all
> > or only for a few specific register accesses.  So taking the lock here
> > in the midlayer is likely unwarranted.  However, changing that requires
> > going through every single driver's ->rs485_config() callback and
> > checking whether it needs the lock or not.
> 
> As a first step its sufficient to take the lock in each drivers rs485_config()
> function and remove it from uart_set_rs485_config(). Then after time sort out
> the drivers that dont require the lock and remove it from their function.
> 
> However the point of this patch was also to generalize the handling of the
> termination GPIO, so I would still see this placed in uart_set_rs485_config().

Additional thing to consider is that core currently handles also the 
port->rs485 assignment under spinlock when ->rs485_config() was 
successful. TIOCSRS485 ioctl calls are synchronized by other primitives 
wrt. each other (port mutex and now also termios_rwsem) but drivers 
probably would like to see consistent rs485 which can only be realized by 
holding port->lock.


-- 
 i.

Re: [PATCH 2/8] serial: core, 8250: set RS485 termination gpio in serial core

[Ilpo Järvinen]

On Sun, 26 Jun 2022, Lino Sanfilippo wrote:

> On 25.06.22 at 21:58, Lukas Wunner wrote:
> > On Wed, Jun 22, 2022 at 05:46:53PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In serial8250_em485_config() the termination GPIO is set with the uart_port
> >> spinlock held. This is an issue if setting the GPIO line can sleep (e.g.
> >> since the concerning GPIO expander is connected via SPI or I2C).
> >>
> >> Fix this by setting the termination line outside of the uart_port spinlock
> >> in the serial core.
> > [...]
> >> --- a/drivers/tty/serial/serial_core.c
> >> +++ b/drivers/tty/serial/serial_core.c
> >> @@ -1400,6 +1411,7 @@ static int uart_set_rs485_config(struct uart_port *port,
> >>  	if (ret)
> >>  		return ret;
> >>  	uart_sanitize_serial_rs485(port, &rs485);
> >> +	uart_set_rs485_termination(port, &rs485);
> >>
> >>  	spin_lock_irqsave(&port->lock, flags);
> >>  	ret = port->rs485_config(port, &rs485);
> >
> > That's one way to solve the issue.  Another would be to push
> > acquisition of the port spinlock down into drivers.
> >
> > I think in most drivers we don't need to take the port spinlock at all
> > or only for a few specific register accesses.  So taking the lock here
> > in the midlayer is likely unwarranted.  However, changing that requires
> > going through every single driver's ->rs485_config() callback and
> > checking whether it needs the lock or not.
> 
> As a first step its sufficient to take the lock in each drivers rs485_config()
> function and remove it from uart_set_rs485_config(). Then after time sort out
> the drivers that dont require the lock and remove it from their function.
> 
> However the point of this patch was also to generalize the handling of the
> termination GPIO, so I would still see this placed in uart_set_rs485_config().

Additional thing to consider is that core currently handles also the 
port->rs485 assignment under spinlock when ->rs485_config() was 
successful. TIOCSRS485 ioctl calls are synchronized by other primitives 
wrt. each other (port mutex and now also termios_rwsem) but drivers 
probably would like to see consistent rs485 which can only be realized by 
holding port->lock.


-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Lino Sanfilippo]

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

Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
into the new function uart_sanitize_serial_rs485_delays().

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 46 ++++++++++++++++++--------------
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index b387376e6fa2..fa6acadd7d0c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1297,27 +1297,9 @@ static int uart_check_rs485_flags(struct uart_port *port, struct serial_rs485 *r
 	return 0;
 }
 
-static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs485 *rs485)
+static void uart_sanitize_serial_rs485_delays(struct uart_port *port,
+					      struct serial_rs485 *rs485)
 {
-	u32 supported_flags = port->rs485_supported->flags;
-
-	if (!(rs485->flags & SER_RS485_ENABLED)) {
-		memset(rs485, 0, sizeof(*rs485));
-		return;
-	}
-
-	/* 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) ==
-	    !(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 (!port->rs485_supported->delay_rts_before_send) {
 		if (rs485->delay_rts_before_send) {
 			dev_warn_ratelimited(port->dev,
@@ -1345,9 +1327,33 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
 			"%s (%d): RTS delay after sending clamped to %u ms\n",
 			port->name, port->line, rs485->delay_rts_after_send);
 	}
+}
+
+static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs485 *rs485)
+{
+	u32 supported_flags = port->rs485_supported->flags;
+
+	if (!(rs485->flags & SER_RS485_ENABLED)) {
+		memset(rs485, 0, sizeof(*rs485));
+		return;
+	}
+
+	/* 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) ==
+	    !(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;
+	}
 
 	rs485->flags &= supported_flags;
 
+	uart_sanitize_serial_rs485_delays(port, rs485);
+
 	/* Return clean padding area to userspace */
 	memset(rs485->padding, 0, sizeof(rs485->padding));
 }
-- 
2.36.1

[PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Lino Sanfilippo]

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

Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
into the new function uart_sanitize_serial_rs485_delays().

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 46 ++++++++++++++++++--------------
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index b387376e6fa2..fa6acadd7d0c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1297,27 +1297,9 @@ static int uart_check_rs485_flags(struct uart_port *port, struct serial_rs485 *r
 	return 0;
 }
 
-static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs485 *rs485)
+static void uart_sanitize_serial_rs485_delays(struct uart_port *port,
+					      struct serial_rs485 *rs485)
 {
-	u32 supported_flags = port->rs485_supported->flags;
-
-	if (!(rs485->flags & SER_RS485_ENABLED)) {
-		memset(rs485, 0, sizeof(*rs485));
-		return;
-	}
-
-	/* 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) ==
-	    !(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 (!port->rs485_supported->delay_rts_before_send) {
 		if (rs485->delay_rts_before_send) {
 			dev_warn_ratelimited(port->dev,
@@ -1345,9 +1327,33 @@ static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs4
 			"%s (%d): RTS delay after sending clamped to %u ms\n",
 			port->name, port->line, rs485->delay_rts_after_send);
 	}
+}
+
+static void uart_sanitize_serial_rs485(struct uart_port *port, struct serial_rs485 *rs485)
+{
+	u32 supported_flags = port->rs485_supported->flags;
+
+	if (!(rs485->flags & SER_RS485_ENABLED)) {
+		memset(rs485, 0, sizeof(*rs485));
+		return;
+	}
+
+	/* 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) ==
+	    !(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;
+	}
 
 	rs485->flags &= supported_flags;
 
+	uart_sanitize_serial_rs485_delays(port, rs485);
+
 	/* Return clean padding area to userspace */
 	memset(rs485->padding, 0, sizeof(rs485->padding));
 }
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
> into the new function uart_sanitize_serial_rs485_delays().

...

> +	/* pick sane settings if the user hasn't */

Be consistent with the style (capitalization) of one-line comments. It might
require another patch to make it all consistent.

(Below is left for a context)

>  	/* Return clean padding area to userspace */

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
> into the new function uart_sanitize_serial_rs485_delays().

...

> +	/* pick sane settings if the user hasn't */

Be consistent with the style (capitalization) of one-line comments. It might
require another patch to make it all consistent.

(Below is left for a context)

>  	/* Return clean padding area to userspace */

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Lino Sanfilippo]

On 23.06.22 at 18:25, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
>> into the new function uart_sanitize_serial_rs485_delays().
>
> ...
>
>> +	/* pick sane settings if the user hasn't */
>
> Be consistent with the style (capitalization) of one-line comments.

Ok, I will adjust this.

> (Below is left for a context)
>
>>  	/* Return clean padding area to userspace */
>
Regards,
Lino

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Lino Sanfilippo]

On 23.06.22 at 18:25, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:54PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
>> into the new function uart_sanitize_serial_rs485_delays().
>
> ...
>
>> +	/* pick sane settings if the user hasn't */
>
> Be consistent with the style (capitalization) of one-line comments.

Ok, I will adjust this.

> (Below is left for a context)
>
>>  	/* Return clean padding area to userspace */
>
Regards,
Lino

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
> into the new function uart_sanitize_serial_rs485_delays().
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

Re: [PATCH 3/8] serial: core: move sanitizing of RS485 delays into own function

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Move the sanitizing of RS485 delays out of uart_sanitize_serial_rs485()
> into the new function uart_sanitize_serial_rs485_delays().
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Lino Sanfilippo]

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

When setting the RS485 configuration from userspace via TIOCSRS485 the
delays are clamped to 100ms. Make this consistent with the values passed
in by means of device tree parameters.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index fa6acadd7d0c..2e9f90e73e62 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
 		rs485conf->delay_rts_after_send = 0;
 	}
 
+	uart_sanitize_serial_rs485_delays(port, rs485conf);
+
 	/*
 	 * Clear full-duplex and enabled flags, set RTS polarity to active high
 	 * to get to a defined state with the following properties:
-- 
2.36.1

[PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Lino Sanfilippo]

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

When setting the RS485 configuration from userspace via TIOCSRS485 the
delays are clamped to 100ms. Make this consistent with the values passed
in by means of device tree parameters.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/serial_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index fa6acadd7d0c..2e9f90e73e62 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
 		rs485conf->delay_rts_after_send = 0;
 	}
 
+	uart_sanitize_serial_rs485_delays(port, rs485conf);
+
 	/*
 	 * Clear full-duplex and enabled flags, set RTS polarity to active high
 	 * to get to a defined state with the following properties:
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> When setting the RS485 configuration from userspace via TIOCSRS485 the
> delays are clamped to 100ms. Make this consistent with the values passed
> in by means of device tree parameters.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/serial_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index fa6acadd7d0c..2e9f90e73e62 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
>  		rs485conf->delay_rts_after_send = 0;
>  	}
>  
> +	uart_sanitize_serial_rs485_delays(port, rs485conf);
> +
>  	/*
>  	 * Clear full-duplex and enabled flags, set RTS polarity to active high
>  	 * to get to a defined state with the following properties:
> -- 
> 2.36.1

While above works, if we go to this change user-visible behavior route, 
uart_get_rs485_mode() could just call full uart_sanitize_serial_rs485()?

The sanitization is currently being done during probe in 
uart_rs485_config() which has another challenge to tackle. The RS485 
supporting UART drivers are not consistently calling it during their 
probe(), only a few of them do but it would make more sense if all of them 
would enter into RS485 mode w/  linux,rs485-enabled-at-boot-time being 
set. However, making such change might run afoul with the expectations of 
users.


-- 
 i.

Re: [PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> When setting the RS485 configuration from userspace via TIOCSRS485 the
> delays are clamped to 100ms. Make this consistent with the values passed
> in by means of device tree parameters.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/serial_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index fa6acadd7d0c..2e9f90e73e62 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
>  		rs485conf->delay_rts_after_send = 0;
>  	}
>  
> +	uart_sanitize_serial_rs485_delays(port, rs485conf);
> +
>  	/*
>  	 * Clear full-duplex and enabled flags, set RTS polarity to active high
>  	 * to get to a defined state with the following properties:
> -- 
> 2.36.1

While above works, if we go to this change user-visible behavior route, 
uart_get_rs485_mode() could just call full uart_sanitize_serial_rs485()?

The sanitization is currently being done during probe in 
uart_rs485_config() which has another challenge to tackle. The RS485 
supporting UART drivers are not consistently calling it during their 
probe(), only a few of them do but it would make more sense if all of them 
would enter into RS485 mode w/  linux,rs485-enabled-at-boot-time being 
set. However, making such change might run afoul with the expectations of 
users.


-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Lino Sanfilippo]

On 25.06.22 at 12:05, Ilpo Järvinen wrote:
> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> When setting the RS485 configuration from userspace via TIOCSRS485 the
>> delays are clamped to 100ms. Make this consistent with the values passed
>> in by means of device tree parameters.
>>
>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>> ---
>>  drivers/tty/serial/serial_core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index fa6acadd7d0c..2e9f90e73e62 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
>>  		rs485conf->delay_rts_after_send = 0;
>>  	}
>>
>> +	uart_sanitize_serial_rs485_delays(port, rs485conf);
>> +
>>  	/*
>>  	 * Clear full-duplex and enabled flags, set RTS polarity to active high
>>  	 * to get to a defined state with the following properties:
>> --
>> 2.36.1
>
> While above works, if we go to this change user-visible behavior route,
> uart_get_rs485_mode() could just call full uart_sanitize_serial_rs485()?

As it is now uart_sanitize_serial_rs485() will clear the entire serial_rs485 struct and
return immediately if rs485-enabled-at-boot-time (and thus SER_RS485_ENABLED)
is not set. That was one of the reasons I moved the delay checks into an own fucntion. The other
reason is that the remaining sanity check for RTS on send/after send in uart_sanitize_serial_rs485() is not
required in uart_get_rs485_mode() since here we already ensure a sane setting.

Regards,
Lino

Re: [PATCH 4/8] serial: core: sanitize RS485 delays read from device tree

[Lino Sanfilippo]

On 25.06.22 at 12:05, Ilpo Järvinen wrote:
> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> When setting the RS485 configuration from userspace via TIOCSRS485 the
>> delays are clamped to 100ms. Make this consistent with the values passed
>> in by means of device tree parameters.
>>
>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>> ---
>>  drivers/tty/serial/serial_core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index fa6acadd7d0c..2e9f90e73e62 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -3382,6 +3382,8 @@ int uart_get_rs485_mode(struct uart_port *port)
>>  		rs485conf->delay_rts_after_send = 0;
>>  	}
>>
>> +	uart_sanitize_serial_rs485_delays(port, rs485conf);
>> +
>>  	/*
>>  	 * Clear full-duplex and enabled flags, set RTS polarity to active high
>>  	 * to get to a defined state with the following properties:
>> --
>> 2.36.1
>
> While above works, if we go to this change user-visible behavior route,
> uart_get_rs485_mode() could just call full uart_sanitize_serial_rs485()?

As it is now uart_sanitize_serial_rs485() will clear the entire serial_rs485 struct and
return immediately if rs485-enabled-at-boot-time (and thus SER_RS485_ENABLED)
is not set. That was one of the reasons I moved the delay checks into an own fucntion. The other
reason is that the remaining sanity check for RTS on send/after send in uart_sanitize_serial_rs485() is not
required in uart_get_rs485_mode() since here we already ensure a sane setting.

Regards,
Lino

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

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

The maximum allowed delay for RTS before and RTS after send is 100 ms.
Adjust the documentation accordingly.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
index f2c9c9fe6aa7..90a1bab40f05 100644
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@ -22,12 +22,12 @@ properties:
         - description: Delay between rts signal and beginning of data sent in
             milliseconds. It corresponds to the delay before sending data.
           default: 0
-          maximum: 1000
+          maximum: 100
         - description: Delay between end of data sent and rts signal in milliseconds.
             It corresponds to the delay after sending data and actual release
             of the line.
           default: 0
-          maximum: 1000
+          maximum: 100
 
   rs485-rts-active-low:
     description: drive RTS low when sending (default is high).
-- 
2.36.1

[PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

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

The maximum allowed delay for RTS before and RTS after send is 100 ms.
Adjust the documentation accordingly.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
index f2c9c9fe6aa7..90a1bab40f05 100644
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@ -22,12 +22,12 @@ properties:
         - description: Delay between rts signal and beginning of data sent in
             milliseconds. It corresponds to the delay before sending data.
           default: 0
-          maximum: 1000
+          maximum: 100
         - description: Delay between end of data sent and rts signal in milliseconds.
             It corresponds to the delay after sending data and actual release
             of the line.
           default: 0
-          maximum: 1000
+          maximum: 100
 
   rs485-rts-active-low:
     description: drive RTS low when sending (default is high).
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> Adjust the documentation accordingly.


Is it only documentation issue? If the code allows this to be set higher
than 100, we may not change the documentation since this an ABI (from
firmware <--> kernel perspective) we need to support old variants.

If the above is true and limit is dictated by the spec, we may issue a
warning in the code and drop it to the allowed maximum, otherwise we
can't do much here.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Andy Shevchenko]

On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> Adjust the documentation accordingly.


Is it only documentation issue? If the code allows this to be set higher
than 100, we may not change the documentation since this an ABI (from
firmware <--> kernel perspective) we need to support old variants.

If the above is true and limit is dictated by the spec, we may issue a
warning in the code and drop it to the allowed maximum, otherwise we
can't do much here.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

On 23.06.22 at 18:29, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> The maximum allowed delay for RTS before and RTS after send is 100 ms.
>> Adjust the documentation accordingly.
>
>
> Is it only documentation issue? If the code allows this to be set higher
> than 100, we may not change the documentation since this an ABI (from
> firmware <--> kernel perspective) we need to support old variants.
>

Well currently the documentation claims that a maximum of 1000 msecs is allowed but
nothing actually checks the values read from device tree/ACPI and so it is possible
to set much higher values (note that the UART drivers dont check the delays read from
DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).

We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.

I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
the sanity checks for TIOCSRS485 were introduced
(see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
since before we did not have those limits for all drivers (some drivers clamped the
values itself but many did not care).
Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
in usecs range). So IMHO the risk is very low to break anything when values are clamped
that are higher than that.


Regards,
Lino

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

On 23.06.22 at 18:29, Andy Shevchenko wrote:
> On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> The maximum allowed delay for RTS before and RTS after send is 100 ms.
>> Adjust the documentation accordingly.
>
>
> Is it only documentation issue? If the code allows this to be set higher
> than 100, we may not change the documentation since this an ABI (from
> firmware <--> kernel perspective) we need to support old variants.
>

Well currently the documentation claims that a maximum of 1000 msecs is allowed but
nothing actually checks the values read from device tree/ACPI and so it is possible
to set much higher values (note that the UART drivers dont check the delays read from
DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).

We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.

I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
the sanity checks for TIOCSRS485 were introduced
(see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
since before we did not have those limits for all drivers (some drivers clamped the
values itself but many did not care).
Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
in usecs range). So IMHO the risk is very low to break anything when values are clamped
that are higher than that.


Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Ilpo Järvinen]

On Thu, 23 Jun 2022, Lino Sanfilippo wrote:

> On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> >> Adjust the documentation accordingly.
> >
> >
> > Is it only documentation issue? If the code allows this to be set higher
> > than 100, we may not change the documentation since this an ABI (from
> > firmware <--> kernel perspective) we need to support old variants.
> >
> 
> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> nothing actually checks the values read from device tree/ACPI and so it is possible
> to set much higher values (note that the UART drivers dont check the delays read from
> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> 
> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> 
> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> the sanity checks for TIOCSRS485 were introduced
> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> since before we did not have those limits for all drivers (some drivers clamped the
> values itself but many did not care).
> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> in usecs range). So IMHO the risk is very low to break anything when values are clamped
> that are higher than that.

Did you see this development direction (from Lukas):

https://lore.kernel.org/linux-serial/20220309125908.GA9283@wunner.de/

?

Effectively, he wants to making a compat threshold at 1msec and beyond 
that the input value would be interpreted as nsecs.

-- 
 i.

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Ilpo Järvinen]

On Thu, 23 Jun 2022, Lino Sanfilippo wrote:

> On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> >> Adjust the documentation accordingly.
> >
> >
> > Is it only documentation issue? If the code allows this to be set higher
> > than 100, we may not change the documentation since this an ABI (from
> > firmware <--> kernel perspective) we need to support old variants.
> >
> 
> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> nothing actually checks the values read from device tree/ACPI and so it is possible
> to set much higher values (note that the UART drivers dont check the delays read from
> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> 
> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> 
> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> the sanity checks for TIOCSRS485 were introduced
> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> since before we did not have those limits for all drivers (some drivers clamped the
> values itself but many did not care).
> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> in usecs range). So IMHO the risk is very low to break anything when values are clamped
> that are higher than that.

Did you see this development direction (from Lukas):

https://lore.kernel.org/linux-serial/20220309125908.GA9283@wunner.de/

?

Effectively, he wants to making a compat threshold at 1msec and beyond 
that the input value would be interpreted as nsecs.

-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

On Sat, 25 Jun 2022, Ilpo Järvinen wrote:

> On Thu, 23 Jun 2022, Lino Sanfilippo wrote:
> 
> > On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> > >>
> > >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> > >> Adjust the documentation accordingly.
> > >
> > >
> > > Is it only documentation issue? If the code allows this to be set higher
> > > than 100, we may not change the documentation since this an ABI (from
> > > firmware <--> kernel perspective) we need to support old variants.
> > >
> > 
> > Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> > nothing actually checks the values read from device tree/ACPI and so it is possible
> > to set much higher values (note that the UART drivers dont check the delays read from
> > DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> > 
> > We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> > consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> > 
> > I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> > the sanity checks for TIOCSRS485 were introduced
> > (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> > since before we did not have those limits for all drivers (some drivers clamped the
> > values itself but many did not care).
> > Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> > in usecs range). So IMHO the risk is very low to break anything when values are clamped
> > that are higher than that.
> 
> Did you see this development direction (from Lukas):
> 
> https://lore.kernel.org/linux-serial/20220309125908.GA9283@wunner.de/
> 
> ?
> 
> Effectively, he wants to making a compat threshold at 1msec and beyond 
> that the input value would be interpreted as nsecs.

I was thinking this more the other day and came up with the idea of adding
SER_RS485_DELAY_RTS_NSEC and SER_RS485_DELAY_RTS_MSEC flags instead of
magic threshold and deprecate specifying those delays w/o either flag. 
That way we'd not need to change behavior and we provide an easy way to 
keep the delay in msec if somebody really wants (just for the sake of 
getting rid of the warning).

-- 
 i.

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

On Sat, 25 Jun 2022, Ilpo Järvinen wrote:

> On Thu, 23 Jun 2022, Lino Sanfilippo wrote:
> 
> > On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> > >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> > >>
> > >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> > >> Adjust the documentation accordingly.
> > >
> > >
> > > Is it only documentation issue? If the code allows this to be set higher
> > > than 100, we may not change the documentation since this an ABI (from
> > > firmware <--> kernel perspective) we need to support old variants.
> > >
> > 
> > Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> > nothing actually checks the values read from device tree/ACPI and so it is possible
> > to set much higher values (note that the UART drivers dont check the delays read from
> > DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> > 
> > We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> > consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> > 
> > I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> > the sanity checks for TIOCSRS485 were introduced
> > (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> > since before we did not have those limits for all drivers (some drivers clamped the
> > values itself but many did not care).
> > Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> > in usecs range). So IMHO the risk is very low to break anything when values are clamped
> > that are higher than that.
> 
> Did you see this development direction (from Lukas):
> 
> https://lore.kernel.org/linux-serial/20220309125908.GA9283@wunner.de/
> 
> ?
> 
> Effectively, he wants to making a compat threshold at 1msec and beyond 
> that the input value would be interpreted as nsecs.

I was thinking this more the other day and came up with the idea of adding
SER_RS485_DELAY_RTS_NSEC and SER_RS485_DELAY_RTS_MSEC flags instead of
magic threshold and deprecate specifying those delays w/o either flag. 
That way we'd not need to change behavior and we provide an easy way to 
keep the delay in msec if somebody really wants (just for the sake of 
getting rid of the warning).

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 10:17:06PM +0200, Lino Sanfilippo wrote:
> On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> >>
> >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> >> Adjust the documentation accordingly.
> >
> > Is it only documentation issue? If the code allows this to be set higher
> > than 100, we may not change the documentation since this an ABI (from
> > firmware <--> kernel perspective) we need to support old variants.
> 
> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> nothing actually checks the values read from device tree/ACPI and so it is possible
> to set much higher values (note that the UART drivers dont check the delays read from
> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> 
> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> 
> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> the sanity checks for TIOCSRS485 were introduced
> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> since before we did not have those limits for all drivers (some drivers clamped the
> values itself but many did not care).
> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> in usecs range). So IMHO the risk is very low to break anything when values are clamped
> that are higher than that.

You need to elaborate all this in the commit message to justify the change.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Andy Shevchenko]

On Thu, Jun 23, 2022 at 10:17:06PM +0200, Lino Sanfilippo wrote:
> On 23.06.22 at 18:29, Andy Shevchenko wrote:
> > On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
> >>
> >> The maximum allowed delay for RTS before and RTS after send is 100 ms.
> >> Adjust the documentation accordingly.
> >
> > Is it only documentation issue? If the code allows this to be set higher
> > than 100, we may not change the documentation since this an ABI (from
> > firmware <--> kernel perspective) we need to support old variants.
> 
> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
> nothing actually checks the values read from device tree/ACPI and so it is possible
> to set much higher values (note that the UART drivers dont check the delays read from
> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
> 
> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
> 
> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
> the sanity checks for TIOCSRS485 were introduced
> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
> since before we did not have those limits for all drivers (some drivers clamped the
> values itself but many did not care).
> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
> in usecs range). So IMHO the risk is very low to break anything when values are clamped
> that are higher than that.

You need to elaborate all this in the commit message to justify the change.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

On 28.06.22 12:03, Andy Shevchenko wrote:
> On Thu, Jun 23, 2022 at 10:17:06PM +0200, Lino Sanfilippo wrote:
>> On 23.06.22 at 18:29, Andy Shevchenko wrote:
>>> On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
>>>>
>>>> The maximum allowed delay for RTS before and RTS after send is 100 ms.
>>>> Adjust the documentation accordingly.
>>>
>>> Is it only documentation issue? If the code allows this to be set higher
>>> than 100, we may not change the documentation since this an ABI (from
>>> firmware <--> kernel perspective) we need to support old variants.
>>
>> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
>> nothing actually checks the values read from device tree/ACPI and so it is possible
>> to set much higher values (note that the UART drivers dont check the delays read from
>> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
>>
>> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
>> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
>>
>> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
>> the sanity checks for TIOCSRS485 were introduced
>> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
>> since before we did not have those limits for all drivers (some drivers clamped the
>> values itself but many did not care).
>> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
>> in usecs range). So IMHO the risk is very low to break anything when values are clamped
>> that are higher than that.
>
> You need to elaborate all this in the commit message to justify the change.
>

OK, I see. I will rewrite the commit message then to hopefully make the rationale behind
the time reduction more clear.

Thanks,
Lino

Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values

[Lino Sanfilippo]

On 28.06.22 12:03, Andy Shevchenko wrote:
> On Thu, Jun 23, 2022 at 10:17:06PM +0200, Lino Sanfilippo wrote:
>> On 23.06.22 at 18:29, Andy Shevchenko wrote:
>>> On Wed, Jun 22, 2022 at 05:46:56PM +0200, Lino Sanfilippo wrote:
>>>>
>>>> The maximum allowed delay for RTS before and RTS after send is 100 ms.
>>>> Adjust the documentation accordingly.
>>>
>>> Is it only documentation issue? If the code allows this to be set higher
>>> than 100, we may not change the documentation since this an ABI (from
>>> firmware <--> kernel perspective) we need to support old variants.
>>
>> Well currently the documentation claims that a maximum of 1000 msecs is allowed but
>> nothing actually checks the values read from device tree/ACPI and so it is possible
>> to set much higher values (note that the UART drivers dont check the delays read from
>> DT/ACPI either, the only exception I found is max310x which clamps it to 15 ms).
>>
>> We already have a maximum of 100 ms defined for RTS delays set via TIOCSRS485. To be
>> consistent with TIOCSRS485 the same limit is used for DT/ACPI values in this patch.
>>
>> I am aware that this changes the firmware/kernel ABI. But we had a similar situation when
>> the sanity checks for TIOCSRS485 were introduced
>> (see https://lore.kernel.org/all/20220410104642.32195-2-LinoSanfilippo@gmx.de/)
>> since before we did not have those limits for all drivers (some drivers clamped the
>> values itself but many did not care).
>> Furthermore 100 ms is already a very high value for RTS delays (which are usually rather
>> in usecs range). So IMHO the risk is very low to break anything when values are clamped
>> that are higher than that.
>
> You need to elaborate all this in the commit message to justify the change.
>

OK, I see. I will rewrite the commit message then to hopefully make the rationale behind
the time reduction more clear.

Thanks,
Lino

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 6/8] serial: 8250_dwlib: remove redundant sanity check for RS485 flags

[Lino Sanfilippo]

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

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_dwlib.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c
index c83e7eaf3877..bed2bd6b7a01 100644
--- a/drivers/tty/serial/8250/8250_dwlib.c
+++ b/drivers/tty/serial/8250/8250_dwlib.c
@@ -95,16 +95,10 @@ static int dw8250_rs485_config(struct uart_port *p, struct serial_rs485 *rs485)
 	if (rs485->flags & SER_RS485_ENABLED) {
 		tcr |= DW_UART_TCR_RS485_EN;
 
-		if (rs485->flags & SER_RS485_RX_DURING_TX) {
+		if (rs485->flags & SER_RS485_RX_DURING_TX)
 			tcr |= DW_UART_TCR_XFER_MODE_DE_DURING_RE;
-		} else {
-			/* HW does not support same DE level for tx and rx */
-			if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
-			    !(rs485->flags & SER_RS485_RTS_AFTER_SEND))
-				return -EINVAL;
-
+		else
 			tcr |= DW_UART_TCR_XFER_MODE_DE_OR_RE;
-		}
 		dw8250_writel_ext(p, DW_UART_DE_EN, 1);
 		dw8250_writel_ext(p, DW_UART_RE_EN, 1);
 	} else {
-- 
2.36.1

[PATCH 6/8] serial: 8250_dwlib: remove redundant sanity check for RS485 flags

[Lino Sanfilippo]

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

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_dwlib.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c
index c83e7eaf3877..bed2bd6b7a01 100644
--- a/drivers/tty/serial/8250/8250_dwlib.c
+++ b/drivers/tty/serial/8250/8250_dwlib.c
@@ -95,16 +95,10 @@ static int dw8250_rs485_config(struct uart_port *p, struct serial_rs485 *rs485)
 	if (rs485->flags & SER_RS485_ENABLED) {
 		tcr |= DW_UART_TCR_RS485_EN;
 
-		if (rs485->flags & SER_RS485_RX_DURING_TX) {
+		if (rs485->flags & SER_RS485_RX_DURING_TX)
 			tcr |= DW_UART_TCR_XFER_MODE_DE_DURING_RE;
-		} else {
-			/* HW does not support same DE level for tx and rx */
-			if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
-			    !(rs485->flags & SER_RS485_RTS_AFTER_SEND))
-				return -EINVAL;
-
+		else
 			tcr |= DW_UART_TCR_XFER_MODE_DE_OR_RE;
-		}
 		dw8250_writel_ext(p, DW_UART_DE_EN, 1);
 		dw8250_writel_ext(p, DW_UART_RE_EN, 1);
 	} else {
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 6/8] serial: 8250_dwlib: remove redundant sanity check for RS485 flags

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Before the drivers rs485_config() function is called the serial core
> already ensures that only one of both options RTS on send or RTS after send
> is set. So remove the concerning sanity check in the driver function to
> avoid redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/8250/8250_dwlib.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c
> index c83e7eaf3877..bed2bd6b7a01 100644
> --- a/drivers/tty/serial/8250/8250_dwlib.c
> +++ b/drivers/tty/serial/8250/8250_dwlib.c
> @@ -95,16 +95,10 @@ static int dw8250_rs485_config(struct uart_port *p, struct serial_rs485 *rs485)
>  	if (rs485->flags & SER_RS485_ENABLED) {
>  		tcr |= DW_UART_TCR_RS485_EN;
>  
> -		if (rs485->flags & SER_RS485_RX_DURING_TX) {
> +		if (rs485->flags & SER_RS485_RX_DURING_TX)
>  			tcr |= DW_UART_TCR_XFER_MODE_DE_DURING_RE;
> -		} else {
> -			/* HW does not support same DE level for tx and rx */
> -			if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> -			    !(rs485->flags & SER_RS485_RTS_AFTER_SEND))
> -				return -EINVAL;
> -
> +		else
>  			tcr |= DW_UART_TCR_XFER_MODE_DE_OR_RE;
> -		}
>  		dw8250_writel_ext(p, DW_UART_DE_EN, 1);
>  		dw8250_writel_ext(p, DW_UART_RE_EN, 1);
>  	} else {
> -- 

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>


-- 
 i.

Re: [PATCH 6/8] serial: 8250_dwlib: remove redundant sanity check for RS485 flags

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Before the drivers rs485_config() function is called the serial core
> already ensures that only one of both options RTS on send or RTS after send
> is set. So remove the concerning sanity check in the driver function to
> avoid redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/8250/8250_dwlib.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_dwlib.c b/drivers/tty/serial/8250/8250_dwlib.c
> index c83e7eaf3877..bed2bd6b7a01 100644
> --- a/drivers/tty/serial/8250/8250_dwlib.c
> +++ b/drivers/tty/serial/8250/8250_dwlib.c
> @@ -95,16 +95,10 @@ static int dw8250_rs485_config(struct uart_port *p, struct serial_rs485 *rs485)
>  	if (rs485->flags & SER_RS485_ENABLED) {
>  		tcr |= DW_UART_TCR_RS485_EN;
>  
> -		if (rs485->flags & SER_RS485_RX_DURING_TX) {
> +		if (rs485->flags & SER_RS485_RX_DURING_TX)
>  			tcr |= DW_UART_TCR_XFER_MODE_DE_DURING_RE;
> -		} else {
> -			/* HW does not support same DE level for tx and rx */
> -			if (!(rs485->flags & SER_RS485_RTS_ON_SEND) ==
> -			    !(rs485->flags & SER_RS485_RTS_AFTER_SEND))
> -				return -EINVAL;
> -
> +		else
>  			tcr |= DW_UART_TCR_XFER_MODE_DE_OR_RE;
> -		}
>  		dw8250_writel_ext(p, DW_UART_DE_EN, 1);
>  		dw8250_writel_ext(p, DW_UART_RE_EN, 1);
>  	} else {
> -- 

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>


-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

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

In uart_set_rs485_config() the serial core already assigns the passed
serial_rs485 struct to the uart port.

So remove the assignment in the drivers rs485_config() function to avoid
redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/ar933x_uart.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
index ab2c5b2a1ce8..857e010d01dc 100644
--- a/drivers/tty/serial/ar933x_uart.c
+++ b/drivers/tty/serial/ar933x_uart.c
@@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
 		dev_err(port->dev, "RS485 needs rts-gpio\n");
 		return 1;
 	}
-	port->rs485 = *rs485conf;
 	return 0;
 }
 
-- 
2.36.1

[PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

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

In uart_set_rs485_config() the serial core already assigns the passed
serial_rs485 struct to the uart port.

So remove the assignment in the drivers rs485_config() function to avoid
redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/ar933x_uart.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
index ab2c5b2a1ce8..857e010d01dc 100644
--- a/drivers/tty/serial/ar933x_uart.c
+++ b/drivers/tty/serial/ar933x_uart.c
@@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
 		dev_err(port->dev, "RS485 needs rts-gpio\n");
 		return 1;
 	}
-	port->rs485 = *rs485conf;
 	return 0;
 }
 
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In uart_set_rs485_config() the serial core already assigns the passed
> serial_rs485 struct to the uart port.
> 
> So remove the assignment in the drivers rs485_config() function to avoid
> redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/ar933x_uart.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
> index ab2c5b2a1ce8..857e010d01dc 100644
> --- a/drivers/tty/serial/ar933x_uart.c
> +++ b/drivers/tty/serial/ar933x_uart.c
> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>  		return 1;
>  	}
> -	port->rs485 = *rs485conf;
>  	return 0;
>  }

Hmm, I realize that for some reason I missed cleaning up this particular 
driver after introducing the serial_rs485 sanitization. It shouldn't need 
that preceeding if block either because ar933x_no_rs485 gets applied if 
there's no rts_gpiod so the core clears SER_RS485_ENABLED.


-- 
 i.

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Ilpo Järvinen]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> In uart_set_rs485_config() the serial core already assigns the passed
> serial_rs485 struct to the uart port.
> 
> So remove the assignment in the drivers rs485_config() function to avoid
> redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  drivers/tty/serial/ar933x_uart.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
> index ab2c5b2a1ce8..857e010d01dc 100644
> --- a/drivers/tty/serial/ar933x_uart.c
> +++ b/drivers/tty/serial/ar933x_uart.c
> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>  		return 1;
>  	}
> -	port->rs485 = *rs485conf;
>  	return 0;
>  }

Hmm, I realize that for some reason I missed cleaning up this particular 
driver after introducing the serial_rs485 sanitization. It shouldn't need 
that preceeding if block either because ar933x_no_rs485 gets applied if 
there's no rts_gpiod so the core clears SER_RS485_ENABLED.


-- 
 i.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

On 25.06.22 at 12:14, Ilpo Järvinen wrote:
> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In uart_set_rs485_config() the serial core already assigns the passed
>> serial_rs485 struct to the uart port.
>>
>> So remove the assignment in the drivers rs485_config() function to avoid
>> redundancy.
>>
>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>> ---
>>  drivers/tty/serial/ar933x_uart.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
>> index ab2c5b2a1ce8..857e010d01dc 100644
>> --- a/drivers/tty/serial/ar933x_uart.c
>> +++ b/drivers/tty/serial/ar933x_uart.c
>> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>>  		return 1;
>>  	}
>> -	port->rs485 = *rs485conf;
>>  	return 0;
>>  }
>
> Hmm, I realize that for some reason I missed cleaning up this particular
> driver after introducing the serial_rs485 sanitization. It shouldn't need
> that preceeding if block either because ar933x_no_rs485 gets applied if
> there's no rts_gpiod so the core clears SER_RS485_ENABLED.
>

I think we still need that "if" in case that RS485 was not enabled at driver
startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
RS485 is enabled via TIOCSRS485.

Maybe in ar933x_uart_probe()

	if ((port->rs485.flags & SER_RS485_ENABLED) &&
	    !up->rts_gpiod) {
		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
		port->rs485.flags &= ~SER_RS485_ENABLED;
		port->rs485_supported = &ar933x_no_rs485;
	}

should rather be

	if (!up->rts_gpiod) {
		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
		port->rs485.flags &= ~SER_RS485_ENABLED;
		port->rs485_supported = &ar933x_no_rs485;
	}




Regards,
Lino

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

On 25.06.22 at 12:14, Ilpo Järvinen wrote:
> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>
>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>
>> In uart_set_rs485_config() the serial core already assigns the passed
>> serial_rs485 struct to the uart port.
>>
>> So remove the assignment in the drivers rs485_config() function to avoid
>> redundancy.
>>
>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>> ---
>>  drivers/tty/serial/ar933x_uart.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
>> index ab2c5b2a1ce8..857e010d01dc 100644
>> --- a/drivers/tty/serial/ar933x_uart.c
>> +++ b/drivers/tty/serial/ar933x_uart.c
>> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>>  		return 1;
>>  	}
>> -	port->rs485 = *rs485conf;
>>  	return 0;
>>  }
>
> Hmm, I realize that for some reason I missed cleaning up this particular
> driver after introducing the serial_rs485 sanitization. It shouldn't need
> that preceeding if block either because ar933x_no_rs485 gets applied if
> there's no rts_gpiod so the core clears SER_RS485_ENABLED.
>

I think we still need that "if" in case that RS485 was not enabled at driver
startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
RS485 is enabled via TIOCSRS485.

Maybe in ar933x_uart_probe()

	if ((port->rs485.flags & SER_RS485_ENABLED) &&
	    !up->rts_gpiod) {
		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
		port->rs485.flags &= ~SER_RS485_ENABLED;
		port->rs485_supported = &ar933x_no_rs485;
	}

should rather be

	if (!up->rts_gpiod) {
		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
		port->rs485.flags &= ~SER_RS485_ENABLED;
		port->rs485_supported = &ar933x_no_rs485;
	}




Regards,
Lino




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

On Sun, 26 Jun 2022, Lino Sanfilippo wrote:

> On 25.06.22 at 12:14, Ilpo Järvinen wrote:
> > On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
> >
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In uart_set_rs485_config() the serial core already assigns the passed
> >> serial_rs485 struct to the uart port.
> >>
> >> So remove the assignment in the drivers rs485_config() function to avoid
> >> redundancy.
> >>
> >> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >> ---
> >>  drivers/tty/serial/ar933x_uart.c | 1 -
> >>  1 file changed, 1 deletion(-)
> >>
> >> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
> >> index ab2c5b2a1ce8..857e010d01dc 100644
> >> --- a/drivers/tty/serial/ar933x_uart.c
> >> +++ b/drivers/tty/serial/ar933x_uart.c
> >> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
> >>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
> >>  		return 1;
> >>  	}
> >> -	port->rs485 = *rs485conf;
> >>  	return 0;
> >>  }
> >
> > Hmm, I realize that for some reason I missed cleaning up this particular
> > driver after introducing the serial_rs485 sanitization. It shouldn't need
> > that preceeding if block either because ar933x_no_rs485 gets applied if
> > there's no rts_gpiod so the core clears SER_RS485_ENABLED.
> 
> I think we still need that "if" in case that RS485 was not enabled at driver
> startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
> RS485 is enabled via TIOCSRS485.
> 
> Maybe in ar933x_uart_probe()
> 
> 	if ((port->rs485.flags & SER_RS485_ENABLED) &&
> 	    !up->rts_gpiod) {
> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
> 		port->rs485.flags &= ~SER_RS485_ENABLED;
> 		port->rs485_supported = &ar933x_no_rs485;
> 	}
> 
> should rather be

I think it would be better (and what I should have done while moving the 
check there in the first place but I missed it). In addition, however, it 
would be useful to not print unnecessarily:

> 	if (!up->rts_gpiod) {

if (port->rs485.flags & SER_RS485_ENABLED) {

> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
> 		port->rs485.flags &= ~SER_RS485_ENABLED;

}

> 		port->rs485_supported = &ar933x_no_rs485;
> 	}

-- 
 i.

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

On Sun, 26 Jun 2022, Lino Sanfilippo wrote:

> On 25.06.22 at 12:14, Ilpo Järvinen wrote:
> > On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
> >
> >> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >>
> >> In uart_set_rs485_config() the serial core already assigns the passed
> >> serial_rs485 struct to the uart port.
> >>
> >> So remove the assignment in the drivers rs485_config() function to avoid
> >> redundancy.
> >>
> >> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> >> ---
> >>  drivers/tty/serial/ar933x_uart.c | 1 -
> >>  1 file changed, 1 deletion(-)
> >>
> >> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
> >> index ab2c5b2a1ce8..857e010d01dc 100644
> >> --- a/drivers/tty/serial/ar933x_uart.c
> >> +++ b/drivers/tty/serial/ar933x_uart.c
> >> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
> >>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
> >>  		return 1;
> >>  	}
> >> -	port->rs485 = *rs485conf;
> >>  	return 0;
> >>  }
> >
> > Hmm, I realize that for some reason I missed cleaning up this particular
> > driver after introducing the serial_rs485 sanitization. It shouldn't need
> > that preceeding if block either because ar933x_no_rs485 gets applied if
> > there's no rts_gpiod so the core clears SER_RS485_ENABLED.
> 
> I think we still need that "if" in case that RS485 was not enabled at driver
> startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
> RS485 is enabled via TIOCSRS485.
> 
> Maybe in ar933x_uart_probe()
> 
> 	if ((port->rs485.flags & SER_RS485_ENABLED) &&
> 	    !up->rts_gpiod) {
> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
> 		port->rs485.flags &= ~SER_RS485_ENABLED;
> 		port->rs485_supported = &ar933x_no_rs485;
> 	}
> 
> should rather be

I think it would be better (and what I should have done while moving the 
check there in the first place but I missed it). In addition, however, it 
would be useful to not print unnecessarily:

> 	if (!up->rts_gpiod) {

if (port->rs485.flags & SER_RS485_ENABLED) {

> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
> 		port->rs485.flags &= ~SER_RS485_ENABLED;

}

> 		port->rs485_supported = &ar933x_no_rs485;
> 	}

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

On 27.06.22 10:14, Ilpo Järvinen wrote:
> On Sun, 26 Jun 2022, Lino Sanfilippo wrote:
>
>> On 25.06.22 at 12:14, Ilpo Järvinen wrote:
>>> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>>>
>>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>>
>>>> In uart_set_rs485_config() the serial core already assigns the passed
>>>> serial_rs485 struct to the uart port.
>>>>
>>>> So remove the assignment in the drivers rs485_config() function to avoid
>>>> redundancy.
>>>>
>>>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>> ---
>>>>  drivers/tty/serial/ar933x_uart.c | 1 -
>>>>  1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
>>>> index ab2c5b2a1ce8..857e010d01dc 100644
>>>> --- a/drivers/tty/serial/ar933x_uart.c
>>>> +++ b/drivers/tty/serial/ar933x_uart.c
>>>> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>>>>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>>>>  		return 1;
>>>>  	}
>>>> -	port->rs485 = *rs485conf;
>>>>  	return 0;
>>>>  }
>>>
>>> Hmm, I realize that for some reason I missed cleaning up this particular
>>> driver after introducing the serial_rs485 sanitization. It shouldn't need
>>> that preceeding if block either because ar933x_no_rs485 gets applied if
>>> there's no rts_gpiod so the core clears SER_RS485_ENABLED.
>>
>> I think we still need that "if" in case that RS485 was not enabled at driver
>> startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
>> RS485 is enabled via TIOCSRS485.
>>
>> Maybe in ar933x_uart_probe()
>>
>> 	if ((port->rs485.flags & SER_RS485_ENABLED) &&
>> 	    !up->rts_gpiod) {
>> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
>> 		port->rs485.flags &= ~SER_RS485_ENABLED;
>> 		port->rs485_supported = &ar933x_no_rs485;
>> 	}
>>
>> should rather be
>
> I think it would be better (and what I should have done while moving the
> check there in the first place but I missed it). In addition, however, it
> would be useful to not print unnecessarily:
>
>> 	if (!up->rts_gpiod) {
>
> if (port->rs485.flags & SER_RS485_ENABLED) {
>
>> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
>> 		port->rs485.flags &= ~SER_RS485_ENABLED;
>
> }


Right. I will send a fix for this with the new version of my series.

Regards,
Lino

Re: [PATCH 7/8] serial: ar933x: Remove redundant assignment in rs485_config

[Lino Sanfilippo]

On 27.06.22 10:14, Ilpo Järvinen wrote:
> On Sun, 26 Jun 2022, Lino Sanfilippo wrote:
>
>> On 25.06.22 at 12:14, Ilpo Järvinen wrote:
>>> On Wed, 22 Jun 2022, Lino Sanfilippo wrote:
>>>
>>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>>
>>>> In uart_set_rs485_config() the serial core already assigns the passed
>>>> serial_rs485 struct to the uart port.
>>>>
>>>> So remove the assignment in the drivers rs485_config() function to avoid
>>>> redundancy.
>>>>
>>>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>> ---
>>>>  drivers/tty/serial/ar933x_uart.c | 1 -
>>>>  1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
>>>> index ab2c5b2a1ce8..857e010d01dc 100644
>>>> --- a/drivers/tty/serial/ar933x_uart.c
>>>> +++ b/drivers/tty/serial/ar933x_uart.c
>>>> @@ -591,7 +591,6 @@ static int ar933x_config_rs485(struct uart_port *port,
>>>>  		dev_err(port->dev, "RS485 needs rts-gpio\n");
>>>>  		return 1;
>>>>  	}
>>>> -	port->rs485 = *rs485conf;
>>>>  	return 0;
>>>>  }
>>>
>>> Hmm, I realize that for some reason I missed cleaning up this particular
>>> driver after introducing the serial_rs485 sanitization. It shouldn't need
>>> that preceeding if block either because ar933x_no_rs485 gets applied if
>>> there's no rts_gpiod so the core clears SER_RS485_ENABLED.
>>
>> I think we still need that "if" in case that RS485 was not enabled at driver
>> startup (no rs485-enabled-at-boot-time) and no RTS GPIO was defined but then
>> RS485 is enabled via TIOCSRS485.
>>
>> Maybe in ar933x_uart_probe()
>>
>> 	if ((port->rs485.flags & SER_RS485_ENABLED) &&
>> 	    !up->rts_gpiod) {
>> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
>> 		port->rs485.flags &= ~SER_RS485_ENABLED;
>> 		port->rs485_supported = &ar933x_no_rs485;
>> 	}
>>
>> should rather be
>
> I think it would be better (and what I should have done while moving the
> check there in the first place but I missed it). In addition, however, it
> would be useful to not print unnecessarily:
>
>> 	if (!up->rts_gpiod) {
>
> if (port->rs485.flags & SER_RS485_ENABLED) {
>
>> 		dev_err(&pdev->dev, "lacking rts-gpio, disabling RS485\n");
>> 		port->rs485.flags &= ~SER_RS485_ENABLED;
>
> }


Right. I will send a fix for this with the new version of my series.

Regards,
Lino



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 8/8] serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

[Lino Sanfilippo]

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

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_lpc18xx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_lpc18xx.c b/drivers/tty/serial/8250/8250_lpc18xx.c
index 3a1cb51cbc91..21896adeb172 100644
--- a/drivers/tty/serial/8250/8250_lpc18xx.c
+++ b/drivers/tty/serial/8250/8250_lpc18xx.c
@@ -44,12 +44,8 @@ static int lpc18xx_rs485_config(struct uart_port *port,
 		rs485_ctrl_reg |= LPC18XX_UART_RS485CTRL_NMMEN |
 				  LPC18XX_UART_RS485CTRL_DCTRL;
 
-		if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+		if (rs485->flags & SER_RS485_RTS_ON_SEND)
 			rs485_ctrl_reg |= LPC18XX_UART_RS485CTRL_OINV;
-			rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
-		} else {
-			rs485->flags |= SER_RS485_RTS_AFTER_SEND;
-		}
 	}
 
 	if (rs485->delay_rts_after_send) {
-- 
2.36.1

[PATCH 8/8] serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

[Lino Sanfilippo]

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

Before the drivers rs485_config() function is called the serial core
already ensures that only one of both options RTS on send or RTS after send
is set. So remove the concerning sanity check in the driver function to
avoid redundancy.

Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
---
 drivers/tty/serial/8250/8250_lpc18xx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_lpc18xx.c b/drivers/tty/serial/8250/8250_lpc18xx.c
index 3a1cb51cbc91..21896adeb172 100644
--- a/drivers/tty/serial/8250/8250_lpc18xx.c
+++ b/drivers/tty/serial/8250/8250_lpc18xx.c
@@ -44,12 +44,8 @@ static int lpc18xx_rs485_config(struct uart_port *port,
 		rs485_ctrl_reg |= LPC18XX_UART_RS485CTRL_NMMEN |
 				  LPC18XX_UART_RS485CTRL_DCTRL;
 
-		if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+		if (rs485->flags & SER_RS485_RTS_ON_SEND)
 			rs485_ctrl_reg |= LPC18XX_UART_RS485CTRL_OINV;
-			rs485->flags &= ~SER_RS485_RTS_AFTER_SEND;
-		} else {
-			rs485->flags |= SER_RS485_RTS_AFTER_SEND;
-		}
 	}
 
 	if (rs485->delay_rts_after_send) {
-- 
2.36.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 8/8] serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Before the drivers rs485_config() function is called the serial core
> already ensures that only one of both options RTS on send or RTS after send
> is set. So remove the concerning sanity check in the driver function to
> avoid redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

Re: [PATCH 8/8] serial: 8250: lpc18xx: Remove redundant sanity check for RS485 flags

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Wed, 22 Jun 2022, Lino Sanfilippo wrote:

> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Before the drivers rs485_config() function is called the serial core
> already ensures that only one of both options RTS on send or RTS after send
> is set. So remove the concerning sanity check in the driver function to
> avoid redundancy.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel