Message ID | 20231013141925.3427158-3-hugo@hugovil.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp1927805vqb; Fri, 13 Oct 2023 07:20:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEja3Be4FrfQDYSimMXnMNOjU3TT/81QxQ5hv3W7w75a1UZTp3XxUNqcrL4y3AflE7Y5CGM X-Received: by 2002:a05:6a00:1d8f:b0:692:afaf:32b4 with SMTP id z15-20020a056a001d8f00b00692afaf32b4mr29101941pfw.0.1697206804278; Fri, 13 Oct 2023 07:20:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697206804; cv=none; d=google.com; s=arc-20160816; b=VTImDCDS9I+e9goVzu9kzGBE84yWwNwHpmwFX9Wo7CnRWAOVum9jrzL16IJvyIS2ZD uze3q9i1s5ubWcN8ubMvMkIhS+KgukgVXJyQRkupYmIzow2fIYc93itmGvPCx/+a61Rl HjdJr7U0mW1hZr36cy/+7950+pJHqm/AmQOWWWvahGUDpv50WnAhvisg96ijVRXlLIfR LIxRw1eKVfNNd/kNLx3jJdcibrw8t6TPVC893RsIItbtiCxsfjvD+E++10vfV8aiKG64 lGen8KX/7s73l5xd94IV8FnkfD4nHBGxzb+r9Ji30mVz/id/uyzUyjzVzeAAro9Xr4kh YIdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:cc:to:from:dkim-signature; bh=iQgc8ugoV+cWytBNeAfWc+zsoe0xTQmmxE4CSL1oZV4=; fh=VMCZnIQaCU4pkoBwVmskDKaTUsCNxL1ek+dzim0+uzY=; b=MiG2fsl0KzmbHSPeesR9yJDEgnt7OW569/OEfwnufiNmdr+1KUQ21Mi+ACeh4e36wO +SmfyxPdZx2d72yU6k75HIDr88oN998xEnHlrBcr0Ft9lKeIiEwR5h94rJXvIYYCsqly MltPbhieAReXl8iYpBZ6ZmYZoHogmcjPb867TCv5/ljfdmuzaEs0CG6AXHLv2J1sO/fO DTfAqp75W1RZtzC7YApU2leKixb8LeiTbUq4/Mj3OKQgqSmEzD1aVTqHg4eT4iEt1HZX lL8myUttpJE5yjCALgsCTCJmD6cuI5Oqm0N2u0yJZVOTxpjrmkVsDLntXOYdAD8+9s5S W8mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hugovil.com header.s=x header.b=LynlOPyJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id s16-20020a056a0008d000b0064f78c32b89si18279314pfu.95.2023.10.13.07.20.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 07:20:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@hugovil.com header.s=x header.b=LynlOPyJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 20B9781E514A; Fri, 13 Oct 2023 07:20:02 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232146AbjJMOTj (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Fri, 13 Oct 2023 10:19:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232034AbjJMOTe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Oct 2023 10:19:34 -0400 Received: from mail.hugovil.com (mail.hugovil.com [162.243.120.170]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 728F6BE; Fri, 13 Oct 2023 07:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hugovil.com ; s=x; h=Subject:Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Cc:To :From:subject:date:message-id:reply-to; bh=iQgc8ugoV+cWytBNeAfWc+zsoe0xTQmmxE4CSL1oZV4=; b=LynlOPyJLi2iPH8rD2ayaq6Uww Zs778MjaKr+WCdxwgB/rn+BIvJgtLBJP9h6n+GE1Q0JmFSsfTeAfVrnT4kUJ3OgXrG9VZKUX1IP0U YiapD9tXhpsP2vf/TI46iWW4JayTBYfWKFANQj/R1VKW88sESy9fRurD9X9JM6jxMn2U=; Received: from modemcable168.174-80-70.mc.videotron.ca ([70.80.174.168]:40430 helo=pettiford.lan) by mail.hugovil.com with esmtpa (Exim 4.92) (envelope-from <hugo@hugovil.com>) id 1qrJ0k-0005Ve-El; Fri, 13 Oct 2023 10:19:31 -0400 From: Hugo Villeneuve <hugo@hugovil.com> To: gregkh@linuxfoundation.org, jirislaby@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, hvilleneuve@dimonoff.com Cc: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, devicetree@vger.kernel.org, hugo@hugovil.com Date: Fri, 13 Oct 2023 10:19:25 -0400 Message-Id: <20231013141925.3427158-3-hugo@hugovil.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20231013141925.3427158-1-hugo@hugovil.com> References: <20231013141925.3427158-1-hugo@hugovil.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 70.80.174.168 X-SA-Exim-Mail-From: hugo@hugovil.com X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 Subject: [PATCH 2/2] dt-bindings: serial: sc16is7xx: remove 'clock-frequency' property X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on mail.hugovil.com) Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Fri, 13 Oct 2023 07:20:02 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779650322145403602 X-GMAIL-MSGID: 1779650322145403602 |
Series |
serial: sc16is7xx: device tree improvements
|
|
Commit Message
Hugo Villeneuve
Oct. 13, 2023, 2:19 p.m. UTC
From: Hugo Villeneuve <hvilleneuve@dimonoff.com> The 'clock-frequency' property is supported but mainly in ACPI-based configurations, for example. This property has therefore no place in the sc16is7xx YAML binding. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> --- .../devicetree/bindings/serial/nxp,sc16is7xx.yaml | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)
Comments
On 13/10/2023 16:19, Hugo Villeneuve wrote: > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > The 'clock-frequency' property is supported but mainly in ACPI-based > configurations, for example. > > This property has therefore no place in the sc16is7xx YAML binding. Please reference commit which you question - 0d447e927. I don't understand why do you remove it. The property was in the original binding. Best regards, Krzysztof
On Mon, 16 Oct 2023 08:09:56 +0200 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > On 13/10/2023 16:19, Hugo Villeneuve wrote: > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com> > > > > The 'clock-frequency' property is supported but mainly in ACPI-based > > configurations, for example. > > > > This property has therefore no place in the sc16is7xx YAML binding. > > Please reference commit which you question - 0d447e927. I don't > understand why do you remove it. The property was in the original binding. Hi, in the max310x YAML conversion review (last week), you told me to drop the clock-frequency from the binding, even if it is supported by the driver, since it is related to ACPI configuration, not DT. The sc16is7xx driver (IC) is very similar to the max310x, and it also supports the clock-frequency property, and I just assumed that its presence in the original text binding was some kind of error or legacy leftover, and would need to be removed based on your comments. Just as a reference, here are the original commits in both drivers that added support for the clock-frequency property: ----------------------- commit d4d6f03c4fb3a91dadfe147b47edd40e4d7e4d36 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Mon May 17 20:29:30 2021 +0300 serial: max310x: Try to get crystal clock rate from property In some configurations, mainly ACPI-based, the clock frequency of the device is supplied by very well established 'clock-frequency' property. Hence, try to get it from the property at last if no other providers are available. commit 24bc6e68efa00f95034dbef0ba91661dd80bd37d Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Mon Mar 18 12:29:15 2019 +0200 serial: sc16is7xx: Respect clock-frequency property If the property is provided and there are no other possibilities to detect UART clock frequency, use it as a fallback. ----------------------- Hugo.
On 16/10/2023 15:58, Hugo Villeneuve wrote: > On Mon, 16 Oct 2023 08:09:56 +0200 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > >> On 13/10/2023 16:19, Hugo Villeneuve wrote: >>> From: Hugo Villeneuve <hvilleneuve@dimonoff.com> >>> >>> The 'clock-frequency' property is supported but mainly in ACPI-based >>> configurations, for example. >>> >>> This property has therefore no place in the sc16is7xx YAML binding. >> >> Please reference commit which you question - 0d447e927. I don't >> understand why do you remove it. The property was in the original binding. > > Hi, > in the max310x YAML conversion review (last week), you told me to > drop the clock-frequency from the binding, even > if it is supported by the driver, since it is related to ACPI > configuration, not DT. Yes, when we talked about max310x. > > The sc16is7xx driver (IC) is very similar to the max310x, and it also > supports the clock-frequency property, and I just assumed that its > presence in the original text binding was some kind of error or legacy > leftover, and would need to be removed based on your comments. But that is not the same and not accurate. clock-frequency was described by the binding. > > Just as a reference, here are the original commits in both drivers that > added support for the clock-frequency property: > > ----------------------- > commit d4d6f03c4fb3a91dadfe147b47edd40e4d7e4d36 > Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Date: Mon May 17 20:29:30 2021 +0300 > > serial: max310x: Try to get crystal clock rate from property > > In some configurations, mainly ACPI-based, the clock frequency of > the device is supplied by very well established 'clock-frequency' > property. Hence, try to get it from the property at last if no other > providers are available. > > > commit 24bc6e68efa00f95034dbef0ba91661dd80bd37d > Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Date: Mon Mar 18 12:29:15 2019 +0200 > > serial: sc16is7xx: Respect clock-frequency property > > If the property is provided and there are no other possibilities to > detect UART clock frequency, use it as a fallback. > ----------------------- These are driver changes. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml index 5dec15b7e7c3..5050176e8b80 100644 --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.yaml @@ -28,13 +28,6 @@ properties: clocks: maxItems: 1 - clock-frequency: - description: - When there is no clock provider visible to the platform, this - is the source crystal or external clock frequency for the IC in Hz. - minimum: 1 - maximum: 80000000 - gpio-controller: true "#gpio-cells": @@ -74,18 +67,13 @@ required: - compatible - reg - interrupts + - clocks allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# - $ref: /schemas/serial/serial.yaml# - $ref: /schemas/serial/rs485.yaml# -oneOf: - - required: - - clocks - - required: - - clock-frequency - unevaluatedProperties: false examples: