diff mbox series

[v2,5/9] dt_bindings: rs485: Correct delay values

Message ID 20220703170039.2058202-6-LinoSanfilippo@gmx.de (mailing list archive)
State New, archived
Headers show
Series Fixes and cleanup for RS485 | expand

Commit Message

Lino Sanfilippo July 3, 2022, 5 p.m. UTC 
From: Lino Sanfilippo <l.sanfilippo@kunbus.com>

Currently the documentation claims that a maximum of 1000 msecs is allowed
for RTS delays. However nothing actually checks the values read from device
tree/ACPI and so it is possible to set much higher values.

There is already a maximum of 100 ms enforced for RTS delays that are set
via the uart TIOCSRS485 ioctl. To be consistent with that use the same
limit for DT/ACPI values.

Although this change is visible to userspace the risk of breaking anything
when reducing the max delays from 1000 to 100 ms should be very low, since
100 ms is already a very high maximum for delays that are usually rather in
the usecs range.

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

Comments

Andy Shevchenko July 3, 2022, 6:36 p.m. UTC | #1 
On Sun, Jul 3, 2022 at 7:02 PM Lino Sanfilippo <LinoSanfilippo@gmx.de> wrote:
>
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>
> Currently the documentation claims that a maximum of 1000 msecs is allowed
> for RTS delays. However nothing actually checks the values read from device
> tree/ACPI and so it is possible to set much higher values.
>
> There is already a maximum of 100 ms enforced for RTS delays that are set
> via the uart TIOCSRS485 ioctl. To be consistent with that use the same
> limit for DT/ACPI values.
>
> Although this change is visible to userspace the risk of breaking anything
> when reducing the max delays from 1000 to 100 ms should be very low, since
> 100 ms is already a very high maximum for delays that are usually rather in
> the usecs range.

Yeah, something similar is what you need to add to the previous patch IIUC.
Rob Herring (Arm) July 5, 2022, 8:38 p.m. UTC | #2 
On Sun, 03 Jul 2022 19:00:35 +0200, Lino Sanfilippo wrote:
> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> 
> Currently the documentation claims that a maximum of 1000 msecs is allowed
> for RTS delays. However nothing actually checks the values read from device
> tree/ACPI and so it is possible to set much higher values.
> 
> There is already a maximum of 100 ms enforced for RTS delays that are set
> via the uart TIOCSRS485 ioctl. To be consistent with that use the same
> limit for DT/ACPI values.
> 
> Although this change is visible to userspace the risk of breaking anything
> when reducing the max delays from 1000 to 100 ms should be very low, since
> 100 ms is already a very high maximum for delays that are usually rather in
> the usecs range.
> 
> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
> ---
>  Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>
diff mbox series

Patch

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).