From patchwork Sun Jul 3 17:00:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lino Sanfilippo X-Patchwork-Id: 587078 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B989CCA473 for ; Sun, 3 Jul 2022 17:01:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231561AbiGCRB4 (ORCPT ); Sun, 3 Jul 2022 13:01:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231909AbiGCRBz (ORCPT ); Sun, 3 Jul 2022 13:01:55 -0400 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 427DC6255; Sun, 3 Jul 2022 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1656867692; bh=EM1zIbFY/PJTPZZLlKcGTkRY1PczN69X+ZbPoyUQEKE=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=G3bWZbl2JaB90fUHC1g/izQgwL/3d0qlV6v3tSQBsHpG78BysBo4wC25NtNBrx7+w g8NIK7REGsDgO86K+v/Ja/wZBFFAh30H0gcqz8QZbdrFEj+0ajdJ618Pq4/bsHa+Fw DZ/8GBvzVjXF6R/mXyx70WHaNLXWwRBI9YBfofyQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from localhost.localdomain ([46.223.3.210]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU9Z-1ndOvI3izr-00eZYA; Sun, 03 Jul 2022 19:01:31 +0200 From: Lino Sanfilippo To: gregkh@linuxfoundation.org, jirislaby@kernel.org Cc: ilpo.jarvinen@linux.intel.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, andriy.shevchenko@linux.intel.com, vz@mleia.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, lukas@wunner.de, p.rosenberger@kunbus.com, Lino Sanfilippo Subject: [PATCH v2 5/9] dt_bindings: rs485: Correct delay values Date: Sun, 3 Jul 2022 19:00:35 +0200 Message-Id: <20220703170039.2058202-6-LinoSanfilippo@gmx.de> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220703170039.2058202-1-LinoSanfilippo@gmx.de> References: <20220703170039.2058202-1-LinoSanfilippo@gmx.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:bHhKUQrpvxEfQLDnA/B6qLNzCXgXuk8x5oOAJ9OM/fcBNvvd46G VxPFhxseBHLy1gfuNFr2susLgd2MviSP9QUS25CF/wjFGsoA8rBUkedVWueukBPXDSfTJKV 30UFURnT7zuEzfu5WGVu9zv6a5/c4MAAM7wSNDzZKIHfx+Jlv2wFCVQSle/Cis61j0aJcW+ eQ0cFQFwBIlPzZncLsjWQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:YCM95pyK50M=:PE9osGNTq6W4U2Rh6hQkj5 gNeGezDhq2uT853atR4YjVF+lv2LA0J0RCzAqLNcaa/tr29AFLMfMGUGb6scYWaaDZTC5MGR9 MBqqK5GZuMpJaORxsL7w9bKvUc6R3jAhUkPFKMaGNiYGLgE00OvJuPaKKOGQJWNeQrQtSCdwK 0mR3m6uFg2KXC5OLBgL23mBJTbN9/cE5aB67jmC/Iko8Dqwzb7ObAST6WYEozpYbOfVNJJzNv 7HZA7kwOZPNEYuWk1CxVPd6xFV67PQ7e2Cmy2Z96JLxixZGSbOQgNTzN8w7WroxnJWXKYbs2P wofIXXgBvl8LxvRg13h+ShDPOovMAD8tRhOuSugkws7LgGNQW/czWYxtjsfQ08YrVoZ/SCmNr 6LvjijvBuk2jgVg2jCnpWIzeBcdC9LMzBiKC4SF/YcJFnuFA+zkyRzQ+W5fvrsMNbIZb2Un3E CZ33kuJnxTp63hoevF41AQ1AkkmRMkLvd5gLJUW3Ujxeplqny8ZBiBwK/ScGmGDr+kyku8r21 ylmHYjYy3nmZAHI4MeGVUqb2W1aMYCDLd7qdLy2CM/fKRYdpGJpPz9VmNp7uOPILrKdymBBeM yI4ZOomHeR/Gev3rTSDICjpWVxmByA2c1B1Q/CQHTfWgMowtOetUVpHY/Oq5JZDjdq9OcXd+t txPq4f8xjdLll2cXy0PvgVuhLYaWyWCQVztT7QeikkK8aIR73oZ8XBDeu+V6dTG8nIh18rYCq DSvQ3pjORN/QMOZ0vv9o+D8Blp3VWUG8rBgeJJ+g3H00BXAp9mopGo/KB6CvbGK1QlzrU3+GW +yoRh19pkwRyHhOqKd39upyBQsLBz/X3FKVcErxHiBMUPFCEfweBvYQQ0bJuF7RtUfdyCmBfE yjwm5ggGIj0oXt2znPXEvi0rhFAXh4mvqlcW1QhNQVcKzcYa8g/4j9xPa/alKiAVp3NRBQg/Q +6ur7alcw3lfjAINLmzPIrSckkYVwSQ27LGrXX/qC+VlyYfW7FuLSdFAxMyhjI4crtsHIN57q 7TBQX/Uez5KYyhSCiCd/CfTXd40cGVOBnN9mBRyLS+1Hn/FQspBp2iTlgYPtQeFCnP/HTlZ8A Ee9+4Z7cqNEMN4uoghE9Q/8p7abMwgTsXcCjgtIIEKh+2blSXRya4zjhA== Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org From: Lino Sanfilippo 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 --- 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).