From patchwork Sun Jul 10 16:44:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lino Sanfilippo X-Patchwork-Id: 590018 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 70224CCA479 for ; Sun, 10 Jul 2022 16:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229491AbiGJQp1 (ORCPT ); Sun, 10 Jul 2022 12:45:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbiGJQpT (ORCPT ); Sun, 10 Jul 2022 12:45:19 -0400 Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F7AA13E13; Sun, 10 Jul 2022 09:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657471497; bh=o+W8ytMepE42gQF0QexTyH8iX1o8DL+6k2p2ZnfEFk0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=JMIVFwwesErimfQUonJfmRcoSxOfdrl41iOeYkn1BO35NjjxibV44eIAl+tb1Y5bY LJuzI8zHM8jg9R4z0aodSebEWWHLeJrZk8XBaCzAJVJxtDoh64f9fr+b9VBrLflTdH dJkWplFgOKHx2InAIcKn0m1Jm2ILT4/4u5iVDg38= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from localhost.localdomain ([46.223.3.243]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMGNC-1ntbQt1ba2-00JJtC; Sun, 10 Jul 2022 18:44:57 +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 v4 5/8] serial: core: sanitize RS485 delays read from device tree Date: Sun, 10 Jul 2022 18:44:39 +0200 Message-Id: <20220710164442.2958979-6-LinoSanfilippo@gmx.de> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220710164442.2958979-1-LinoSanfilippo@gmx.de> References: <20220710164442.2958979-1-LinoSanfilippo@gmx.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:BmyX5I0qt+OesHVxffLQ/vKe7NwrSCOmcs5z8TkhMlNjqTio3Bg dJfSZy76tfO6/ooi+mv9cEpVLH/02a+wL9nR+oItjKClHXcbrg8mr8PiXXxtLjOyHG4Qf5l 0NnfIwpYhzISa8MTQuKj4S3IwUTKH2eLM6S6FiIQnHsMg2/88jkKTdititWojJvdn36qsx9 nBOLgWTbbAbxF71M5YAiw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ya4pN4diymI=:kl+/LelUjlM4BTT4Ugt+LO rKUM5oSNJeLUqW19kw36LgNFqbF85JGwHMo8cfxcGMJ2AGY92gz9hvLumPqy7PqkcB6uJ1RnM mGpDxTMqUDpD5MsmjliyF8HCuZyuHzXgN/oTK6qkauG25KTJrSBZu1ShGbwWJfBsW+rtGItC0 STM+tphrmp0Ylj6MvQ/soJyQl7wDdgjf5d7OE5Lm5rxUnWhHxiHL+KWb+rzxaS4xQfU2C5hk/ E5kC6No2zl281vgmMnBM7WzB2TWvkzRA1Uf7Wat6lhvaQ27+ZE+8Qd+cS5zsG5OSwAB4sDm7X k8HQIF3c4Sw22Kqq6G/1L/Ms8IHRG+ES3gTM3h+GprixZWS7C0qGCpgvHLrVa+f7uhxahS8r6 2jSt/9d1Ozw7GLhDDlGv9dIXHx+nl8ccWKoOv3vzbFw30fsjk8y/XQ17Fj24jlKjHVxc+dedk aCNt9d3mENQZRaPwfT5xG7Ir2FHFcJEru+ZK8J/LcptFHiF6Eh7V/ySFyRL0RkvsUg6usho3v DipBL3fcDqAz6bSjYwbvLDoifAXbCFKlEoBQUPDezPunmIHiduv2xEl/yruwPo1Mu2cVTWq12 ACmYxPzyVps9f/ab+38WsDpWb1BVcZaLJiznX0e3sWVG9Lh6zHQ9J/DrnV3LlK39YtgehytPp /Ilmo4n6ZHcmLctHk+wpysz4dvxztCbzgfcIey8D9VyRdycNRz/Xvv9mhJ+fbKOuc67CRgqfQ OjfH7wNyaAMz55GyuNFqCRI62h5dRcBoBSFi94kEz9K4DVvMy28kfZ1sg5Ft6kkn6CjiHNETI g3LTaj7pWWYnPevaVcOSmNgRAqhQjBri7fBHZT3vgW0jMNZjxKw7ukXsAHaAE2KhEaobt6WTk Sat3kz9IS4RDtj8WbfM9VvA2xpMFPAyN43rHWoV9Mw8J0ZT1xKAWWZfxLJoI9iub/Vu3c5Y/H yLWB/+FZpXkoSA3V/Ni4rwrpv2o4WpygYcVCYM1UiPfvW8mdeTmYEsUuy2N9PlP2dXGD/mZV8 nQw3qgPKB6cvDOP6qie8cAsdpHVSbF8BMoHeZqGkXIx2RxfYuJ0SlSzP+4V4u3u51K9GKMbiu Ot3zsSWaB68U3UUyfKuLXNV/Oannn//xMk1IGYC/5u+ShCNmFd4Yt6B8Q== Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org From: Lino Sanfilippo Currently the RTS delays set via device tree are not clamped to a maximum value although the device tree bindings documentation for RS485 claims that only a maximum of 1000 msecs is allowed. So clamp the values to avoid arbitrary high delay settings. However clamp the values to 100 instead of 1000 msecs to be consistent which the maximum that is allowed when setting the delays from userspace via the UART ioctl TIOCSRS485. Signed-off-by: Lino Sanfilippo --- 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 3158f05a328c..ac198d0d4c80 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3395,6 +3395,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: