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 X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E419C433B4 for ; Wed, 21 Apr 2021 22:33:53 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E8BDE613FB for ; Wed, 21 Apr 2021 22:33:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8BDE613FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=Z2g+HPpRGGB/L5BxS0qex8Zcao/aCaOg0o33BTYF9mE=; b=jSYzwEgHMbZS+uttHHEfHenrQ AxaVEoVQRyQAHzTifaiRqHeHjU1GJQ4j72suwj2Hr1/7i2YIQV7fssz8MtYOgEbgpSofCtkONZX1r 62+h2QfXPaWkehd7gTpuKE31EHKDhW2uaUP8tk8ihHOd0AYEv0NeJMTzdSVradMBVl1EctP6RS8II mCUD8AolhfWoY1mkdlM3wdasSHQMz16RzO1bMKbQJZpiT33CoYgGHonEuxW1WQF4NnaMlORByZ6ix CmRv5P4z0/FATt39ZlLumSEzaH0LCdTjiKqmxDIvtudjIuXYR6Bs4z4nI10vB8wc3Gsefc3UpHQZd P4Jv95FLg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZLO1-00FIc9-Ex; Wed, 21 Apr 2021 22:31:57 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZLNy-00FIbJ-CJ for linux-arm-kernel@desiato.infradead.org; Wed, 21 Apr 2021 22:31:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=pJS91dUrjK9PabCMqdvfN/5r3xfPYnYNUCDr56dm7/I=; b=abxpVdC+kyoaFw891Fn7JhYtJ7 vPapfXPOWnyNJIpeQpKaPFNbIdkuXo9iIZI6nJYS4kG4ECp9O9JGIdsnSgsqUuCjCrkgdm4xQmdr4 1AA4rsnigBfQliqupwukUDyShsoc/GFAm1msfI9zX3i1q7J9wuYEhpe8X6fnvK0i9EXvR34FHHVI+ kJPzp3H2gx5f60b/9XOPMFiH/Yr8WpNN73b4TNxetOmhPK6EsButHImL186diDq0Jh3i0j24vYmCy uVVfwojT3S2Hq1NSblcSRXppiaXBWTkzueimptDBSZc5BbbusGqioUQK9p2fJlnX4IiH8zDm27dv7 5a5lUBbw==; Received: from mail-oi1-f171.google.com ([209.85.167.171]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZLNv-00DERb-CT for linux-arm-kernel@lists.infradead.org; Wed, 21 Apr 2021 22:31:53 +0000 Received: by mail-oi1-f171.google.com with SMTP id l17so12616503oil.11 for ; Wed, 21 Apr 2021 15:31:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pJS91dUrjK9PabCMqdvfN/5r3xfPYnYNUCDr56dm7/I=; b=GGxdN18K5Si5P9WGSeHu0bhKdLkA2Znwsfum7RmCSgYzqvNCtpX91t9u3IJXZ4iMZQ OILHYNW8hIdYry5Q7/atfGhLNBGizDyeRCZGs6/FqlHvWgDFvy6gdiif3HqnrMWPTNIz 1Vnkci+FMrNY8bWvYO/SfKud+9a4/2vvfzOdVk/V9YC38GsaxZN+eIJ1myPbGxs9lpmC cAkyiRZJo3UnFp/0bLlFs9D6zD/A1J8nOjDSWzRxRSFe/lv34m9x/Lz6jA2yomKfgSSq nLLloHZztpzBbdM3DO7pxBkbgeVZLqXkDhmMGiG45nvnUs5T0uTu3lWUEnglA9isoTQK NVIw== X-Gm-Message-State: AOAM530C4poRHwuuUhXJFXUq2/Mah14eQ4vK89DApEEurG76gyVshGVW jKaeU/iuZ7xIGTqTZAvR7Q== X-Google-Smtp-Source: ABdhPJyltzopczGcfV9YdI2XwlbbJwZKn7Mm+TtioesKy0/KPoYSSRr44ytf6rEtkn2vqyFLWiuCpw== X-Received: by 2002:aca:aa10:: with SMTP id t16mr8090448oie.57.1619044307045; Wed, 21 Apr 2021 15:31:47 -0700 (PDT) Received: from robh.at.kernel.org (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id d16sm180662ote.56.2021.04.21.15.31.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 15:31:46 -0700 (PDT) Received: (nullmailer pid 1733632 invoked by uid 1000); Wed, 21 Apr 2021 22:31:45 -0000 Date: Wed, 21 Apr 2021 17:31:45 -0500 From: Rob Herring To: Nishanth Menon Cc: Stephen Boyd , Michael Turquette , Philipp Zabel , Santosh Shilimkar , Tero Kristo , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema Message-ID: <20210421223145.GB1705110@robh.at.kernel.org> References: <20210416063721.20538-1-nm@ti.com> <20210416063721.20538-3-nm@ti.com> <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com> <20210417125127.vigq23mdoodje6b5@velcro> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210417125127.vigq23mdoodje6b5@velcro> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210421_153151_522994_C4BC33F1 X-CRM114-Status: GOOD ( 29.97 ) 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 Sat, Apr 17, 2021 at 07:51:27AM -0500, Nishanth Menon wrote: > On 16:55-20210416, Stephen Boyd wrote: > > Quoting Nishanth Menon (2021-04-15 23:37:19) > > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > > new file mode 100644 > > > index 000000000000..72633651f0c7 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > > @@ -0,0 +1,52 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: TI-SCI clock controller node bindings > > > + > > > +maintainers: > > > + - Nishanth Menon > > > + > > > +allOf: > > > + - $ref: /schemas/clock/clock.yaml# > > > > Is this needed? No. It is already applied to every node. > https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml > This standardizes provider properties like '#clock-cells' etc, allowing > you to add more stricter checks or controls in the future if necessary. > > while: > > https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml > is more a consumer node description. No, the meta-schema is what checks the schemas just as the schemas check dts files. > Should I have picked a different yaml as base for a standard clock-controller > base? > > > > > > + > > > +description: | > > > + Some TI SoCs contain a system controller (like the Power Management Micro > > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling > > > + the state of the various hardware modules present on the SoC. Communication > > > + between the host processor running an OS and the system controller happens > > > + through a protocol called TI System Control Interface (TI-SCI protocol). > > > + > > > + This clock controller node uses the TI SCI protocol to perform various clock > > > + management of various hardware modules (devices) present on the SoC. This > > > + node must be a child node of the associated TI-SCI system controller node. > > > + > > > +properties: > > > + $nodename: > > > + pattern: "^clock-controller$" > > > > Is this nodename pattern check required? > > I'd like the definition on rails and not subject to interpretation, and > restrict the kind of subnodes under TISCI controller node. If this schema was standalone and not defined as part of another, then yes it would be required. In your case, you can enforce the node name from the parent schema. For consistency though, it would be better to just always require $nodename. Actually, this schema will be applied twice. On it's own matching the compatible string and by the parent schema. You can prevent that with 'select: false'. I don't mind the double validation as if the parent node had a compatible typo you'd get zero validation. > > > > > > + > > > + compatible: > > > + const: ti,k2g-sci-clk > > > > I thought most things keyed off the compatible string. > > Yes, they are. I am not sure I understand your question here. Did you > mean to indicate that having $nodename and compatible both are > redundant? > > Redundancy was'nt the intent of this schema definition, rather, I'd like > to make sure that it is not upto interpretation or debate as to what the > node name should be: I believe clock-controller is the correct nodename > (without @0x... since this does'nt use reg property) instead of using > clocks, tisci-clock as the node names. > > > Do you suggest something different? > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel