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 24865C54E94 for ; Wed, 25 Jan 2023 13:45:15 +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=Mb2r1Tvd+AiqpS0BQ86qoT9j/7xqVFHLlYRAXfXaz4Q=; b=fu+U/rJtnQSde5 iGA3CvH3lpSMJuyqVpUr85wG+6PoHBYMTDyUbsaGA+vury2rOP7i5w6xfKG5hTqm2UBf9YzYeGwFd rvtMqw7frbhVK32yRJEssmExKJLdu9u3KVlEoCktELndNX+f/YsabitiqYRYI9+dGcckq07tghtbn wIcqX2kfWAiYl7BsDSzQbQvbq6pY5UOqM2jJvtdMeOAogC+TKOSKhvkJ+RTg4QJG8gk/IvGTa3W3g vvtS+OP0LCbEnmXZb1JqHInlI66JwethNOTNErTcdwKIeZuPiCejyfnbsAeWz7tKzOVlB+yAI8Xfd nVb4Q5aFMDlEZeLtJrKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pKg4J-007Q8r-HU; Wed, 25 Jan 2023 13:44:03 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pKg4F-007Q7l-1y for linux-arm-kernel@lists.infradead.org; Wed, 25 Jan 2023 13:44:01 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 741064B3; Wed, 25 Jan 2023 05:44:33 -0800 (PST) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A991C3F71E; Wed, 25 Jan 2023 05:43:50 -0800 (PST) Date: Wed, 25 Jan 2023 13:43:48 +0000 From: Cristian Marussi To: Rob Herring Cc: Sudeep Holla , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child node properties Message-ID: References: <20230124222023.316089-1-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230124222023.316089-1-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230125_054359_230437_597EE58A X-CRM114-Status: GOOD ( 21.58 ) 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 Tue, Jan 24, 2023 at 04:20:23PM -0600, Rob Herring wrote: > The SCMI protocol child nodes are missing any constraints on unknown > properties. Specifically, either 'unevaluatedProperties' or > 'additionalProperties' is needed. The current structure with a regex > match for all child nodes doesn't work for this purpose, so let's move > the common properties '$defs' entry which each specific protocol node > can reference and set 'unevaluatedProperties: false'. > Hi Rob, > Signed-off-by: Rob Herring > --- > .../bindings/firmware/arm,scmi.yaml | 43 ++++++++++++++----- > 1 file changed, 33 insertions(+), 10 deletions(-) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index 176796931a22..2f7c51c75e85 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -100,7 +100,9 @@ properties: > Channel specifier required when using OP-TEE transport. > > protocol@11: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x11 > @@ -112,7 +114,9 @@ properties: > - '#power-domain-cells' > > protocol@13: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x13 > @@ -124,7 +128,9 @@ properties: > - '#clock-cells' > > protocol@14: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x14 > @@ -136,7 +142,9 @@ properties: > - '#clock-cells' > > protocol@15: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x15 > @@ -148,7 +156,9 @@ properties: > - '#thermal-sensor-cells' > > protocol@16: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x16 > @@ -160,20 +170,31 @@ properties: > - '#reset-cells' > > protocol@17: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x17 > > regulators: > type: object > + additionalProperties: false > description: > The list of all regulators provided by this SCMI controller. > > + properties: > + '#address-cells': > + const: 1 > + > + '#size-cells': > + const: 0 > + > patternProperties: > - '^regulators@[0-9a-f]+$': > + '^regulator@[0-9a-f]+$': > type: object > $ref: "../regulator/regulator.yaml#" > + unevaluatedProperties: false > > properties: > reg: > @@ -184,15 +205,17 @@ properties: > - reg > > protocol@18: > - type: object > + $ref: '#/$defs/protocol-node' > + unevaluatedProperties: false > + > properties: > reg: > const: 0x18 > > additionalProperties: false > > -patternProperties: > - '^protocol@[0-9a-f]+$': > +$defs: > + protocol-node: > type: object > description: so now that the catch-all protocol@ patternProperty is gone in favour of the 'protocol-node' definition and $refs, does that mean that any current and future SCMI officially published protocol has to be added to the above explicit protocol list, even though it does not have any special additional required property beside reg ? (like protocol@18 above...) As an example SystemPower protocol@12 is not listed above too and it has nothing more than a reg=0x12 prop (liek 0x18), but before this patch was 'covered' by the patternProperty (so Krzysztof shot down, rightly, my recent attempt to add a distinct protocol@12 def), but now it does not seem anymore the case...so will we need to add an explicit protocol node for any future protocol addition ? (SCMI is extensible up to 255 protos..) Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel