From mboxrd@z Thu Jan 1 00:00:00 1970 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 711E8CCA481 for ; Tue, 28 Jun 2022 10:03:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344715AbiF1KDu (ORCPT ); Tue, 28 Jun 2022 06:03:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344635AbiF1KDX (ORCPT ); Tue, 28 Jun 2022 06:03:23 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 401642E9E9; Tue, 28 Jun 2022 03:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656410602; x=1687946602; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6F1wA0MP/XvdHSRksenwLF7TskHY3KOWwY3P9Ta6U+I=; b=FtrVIO1vHiaP29zgONSRl4tI3ttpj3leE5JcAqttb5gNs+KQaH5WIHwo dOvSOIsfcrMEYZj8ahsSV0GMUNccRY35Mg7QHMAbv5z7u746aGl3KU5iV ax4KAs/0vh2T5JPkjDWSLzuHHuXs5pIDf+VNojsAu60ODycGYZCemPt19 ETJz0DrDp3R3PqQUn7jZJoGyAWTHJh7ef5FUxpNsZ+b8dPaAtH4G+nFO1 ULD6djPC4ZKciziPvW+gPICxAgRNuWK5AUd7lSBqf0jPfJy3bTiDAMEXI XkRse2XdR1CwdRlbDzf+2eX3hwEDvJNxt9l/LzrLc1lXDn1JQev2JdOWZ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="282790166" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="282790166" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 03:03:21 -0700 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="590261183" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 03:03:18 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1o683u-000wgu-T2; Tue, 28 Jun 2022 13:03:14 +0300 Date: Tue, 28 Jun 2022 13:03:14 +0300 From: Andy Shevchenko To: Lino Sanfilippo Cc: gregkh@linuxfoundation.org, jirislaby@kernel.org, ilpo.jarvinen@linux.intel.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, 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: Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values Message-ID: References: <20220622154659.8710-1-LinoSanfilippo@gmx.de> <20220622154659.8710-6-LinoSanfilippo@gmx.de> <6c50fdca-aac4-aaf5-ad34-18a60fcc0aa0@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c50fdca-aac4-aaf5-ad34-18a60fcc0aa0@gmx.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BC3F6C433EF for ; Tue, 28 Jun 2022 10:04:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+CnkS6i9hxGrPKHessC6gUQRWN43jIKUkStc3nKeikk=; b=ZbpzjDwcDmhNgR zQeTVEUbmg2ykieeCk6IhNuyPFCFI6bvsfFcXtZrFrwyw1MaRWiPtazsxKAsxQ2r9uOqlsB3yEHbz jcEUNaI4PNYdkiC3k0x/lWunjCOqtvIkYMgeNYE43n467xKKKEYhahOGIYEEqc/QrlLIdpnV/SqZE UjkcyC5C44gHVYorI2QaA4hEVsLQ+jMKdfLSmJzqurp3t6wH97qHx9462MaQsqwdtRN1mTYQYNhzH Uwp8J+/yqiKXL9G5NHa1GuPuLv5IrSgNgwrXjbYw+Vs4tvxwXyCY/P2byy+XYz3MNs7eNs40HE9wS uxC7fnKz+SXfQuJ4TcHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o684H-005cqz-Ky; Tue, 28 Jun 2022 10:03:37 +0000 Received: from mga05.intel.com ([192.55.52.43]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o684E-005cnJ-MM for linux-arm-kernel@lists.infradead.org; Tue, 28 Jun 2022 10:03:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656410614; x=1687946614; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6F1wA0MP/XvdHSRksenwLF7TskHY3KOWwY3P9Ta6U+I=; b=e4oWkmS1rWxzonfFdiIMl+WVZh3vnBydRNOIl3zqp2/j1FwMszYoe3x6 1UZaTII3ud+PLYYuQagb7V2BYqPvvtR8w0ltsTQaeUqpXtRjxyUEf8LET b2PxzMf1TvLYdwLsNddE55XirTCx4I8AutZUmaDupdiEIai1+ErgGsad3 0Pv+XiAlh4hv0AUtLKkzPNh1O5vv6Uow8BbtXNaKe3S5ZjUPZBh1KJo6r RoLeBceTu81B1eE121AvEN+8/lwVxJP7l9UpxEqRacnG4or7jtrT4c6Qx 1KEcxlvMa/05Wyb+fdasSoevhT5qM4gpx4wxzfYIe8/QH721to2ni5Tva Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="368011283" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="368011283" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 03:03:22 -0700 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="590261183" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 03:03:18 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1o683u-000wgu-T2; Tue, 28 Jun 2022 13:03:14 +0300 Date: Tue, 28 Jun 2022 13:03:14 +0300 From: Andy Shevchenko To: Lino Sanfilippo Cc: gregkh@linuxfoundation.org, jirislaby@kernel.org, ilpo.jarvinen@linux.intel.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, 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: Re: [PATCH 5/8] dt_bindings: rs485: Correct delay values Message-ID: References: <20220622154659.8710-1-LinoSanfilippo@gmx.de> <20220622154659.8710-6-LinoSanfilippo@gmx.de> <6c50fdca-aac4-aaf5-ad34-18a60fcc0aa0@gmx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6c50fdca-aac4-aaf5-ad34-18a60fcc0aa0@gmx.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220628_030334_782502_999436EC X-CRM114-Status: GOOD ( 22.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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