From patchwork Sun Jul 10 15:03:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lino Sanfilippo X-Patchwork-Id: 589337 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 727C3C433EF for ; Sun, 10 Jul 2022 15:03:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229478AbiGJPDx (ORCPT ); Sun, 10 Jul 2022 11:03:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbiGJPDw (ORCPT ); Sun, 10 Jul 2022 11:03:52 -0400 Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB78664C9; Sun, 10 Jul 2022 08:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657465411; bh=+fmYvZVXamDwJB1kParFdNMn3bLBWfn1dkqM/yC5mIQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=f9oarPSz50faR9fqgIqFdwEidGXgoWiiLKWRC8ZULN3yoLiaufw6nG5kbt+oUY5my ernFkTEptbd0oqiSAuky8iZkJ6Qjh86ns1mtZcbN/XELLhzUfBH8NTExnKhkXY/xmf oE/9MejjkU+jrQl8GsTTUCTPNPl+TKpFruPAZYH4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from localhost.localdomain ([46.223.3.243]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4s4r-1oBNoa1hUV-001xh4; Sun, 10 Jul 2022 17:03: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 v3 5/8] serial: core: sanitize RS485 delays read from device tree Date: Sun, 10 Jul 2022 17:03:19 +0200 Message-Id: <20220710150322.2846170-6-LinoSanfilippo@gmx.de> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220710150322.2846170-1-LinoSanfilippo@gmx.de> References: <20220710150322.2846170-1-LinoSanfilippo@gmx.de> MIME-Version: 1.0 X-Provags-ID: V03:K1:2ZsPcOiZ5Mc/6S7zDjUbGiEU3WBBNjfP8QdAjZZG7E/rqnT/FJa vIYzeakLH3ICKvf5VHkJEPkjnoYSn66Pi0rvxgOUtCRfjSzmukj4YcewZSbPIckLL7BDzqB AN3HuyAfZF7sVMCnW0EOVrYsyswLNxDj7HxMkgRtovGkKvRmcsEQwY9FrOf/60baCc7sWRz N8Vq7yJeJ+2A/TpWYwrQA== X-UI-Out-Filterresults: notjunk:1;V03:K0:6j6GiID7VR0=:p7QB+QX/zyq23lxlxhIM3Z RIg6TG4+oAUUv1saM4BNFwtW93qiPJkDIU10hl8XkFKiBF9qNcPPHywvBSeI4jxpGMxt+UQ5o Ha2Z1qD1FTtercN0Npu8BJTJ9Fns2/uYDEiYxip5b3qCDw5Z05T0p6ruyHcoZjRZWBZEqcOos PiliK6ncvMDJCJ1MaqYTdGZr9X9pwCe4vPXe+Ilwp0/PQDhLyht3vAbZc8V5Jd1Uxr6DegM4+ Ox6o8CKYAXPtcEasa+GxhvPnnqwxaEi7n4YuAoBRliG8cLlSTqqk40gMaCvujkg61os6PPLrU NxR6dPA/aF81TtKrSZmMcRH6G0i4tvJavlZBohGLdAVmRlWvpeoZJHv0wXV7awQJQT1sFvotY NSUrOBpf/TiaSZsF0b/afdGaaN5g5CTIFwhacgfoTiDJ6EPY5Y1V6+FJLEzl0qqhnIrnVgo8b LNa8CG4aHbFfHta6NRVL6/7NNxP8n/UZzz6pj/GfLRqe/rq5jE1gKaGh7AsNUmgQZAcqmdtVX ANIXU8Mt8pkPiIcxk5prLHw2Kn9GYN69p5q+kLlfSmIg6x/skPXZQDInjZJJQYfaDSLeoWsMd 72Qh82yMJEExhLIT7nkW1xwpYWkWFNcvMNQvWWMXTXXq+ALBBI5VqC16lXkD6/VyBiG1c1Mod iNmYvwhf7jZ1ekH8JhEDJKJ4WtLYZxTkTP/OL9eKk5ZPS2M4jc2tga+MOVEAQ3Q/KPLDZFEYV ZCgOGwM34r4u4dLvkVJIAvv4KvZYrExz9Se+QTIQyuwNdG2KCgl9dLMcQ0E54Z7833OF0addm +HZ+unJ3aBN4JwK0bbNyWdiVJeKOFuQtJg4cYUgMlMixszlj7QyWOI/hWw97ecSkz2s9g5moR IF1BZ8Bz4C3RnpPbShCN2ITZdf4XbEPtdzpLN+EtbWyw/xHfRJdWgTdfrdkC7MOBbtwpGUQv3 EHz477JHLFq9991NlTGBWBpD0nsV/S7Z5IjD/0eIdAo++v/vBU+JI7d8G9oCXzXRRGLf/ceKt jy43ZKwSWX/FvD9ZpfQzKIcKf7PejunyIniEwWMwMhuwH22VnNG0o29v7VHqSQ5voVHWRkLo0 QsGYqT7FG3ROLCNFyUAzuWjl50V6qTEGzJhXrQtzDYVl7F/FvOwC1yY9g== 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 5943cb35556f..2c4d52b37596 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: