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 C24A0C77B7A for ; Tue, 6 Jun 2023 11:09:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236496AbjFFLJO (ORCPT ); Tue, 6 Jun 2023 07:09:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236696AbjFFLIj (ORCPT ); Tue, 6 Jun 2023 07:08:39 -0400 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64425198C; Tue, 6 Jun 2023 04:07:26 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1686049644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=09M+g6gmWXcLOlBrqcMFpDqHK+MqU1CBFEr/Ok+0g8I=; b=AQpOpxdw1CqkMeYpVcOKhMeqrhBhfnWmdaUaItWRJoZMp3S1lZMh4M+NvPjloiNQJfZdnh /TN6xPwnB+jTieCuPmAea+CetcLysfPg3yDjjgu6bjEJ/hhr/t/EXo2vEDRAdi4qVbKeOg ix8QSQHY401UTJve/0F8BV6M+HhWVmIpw689AERXV2DPNkBsjd207iNS1Xw2YYMWlqabif JEpP/7fnNE1ogD79oqySl2XUCUPJKqudU1wa+3x1LP52wU2zfZS0dBDudr2vD2kzNHDY9a +z91WzYciBYLXk3w7Nc9cvG8KT2AELvKyNHqW1UV6fj4RuXY63e+ylv3iqVeuw== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id ADE5CE000D; Tue, 6 Jun 2023 11:07:20 +0000 (UTC) Date: Tue, 6 Jun 2023 13:07:19 +0200 From: Miquel Raynal To: Krzysztof Kozlowski Cc: Chris Packham , "richard@nod.at" , "vigneshr@ti.com" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "conor+dt@kernel.org" , "andrew@lunn.ch" , "gregory.clement@bootlin.com" , "sebastian.hesselbarth@gmail.com" , "conor@kernel.org" , "linux-mtd@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "enachman@marvell.com" , Vadym Kochan Subject: Re: [PATCH v8 3/3] dt-bindings: mtd: marvell-nand: Convert to YAML DT scheme Message-ID: <20230606130719.5350174c@xps-13> In-Reply-To: <20230606125724.126a4685@xps-13> References: <20230531234923.2307013-1-chris.packham@alliedtelesis.co.nz> <20230531234923.2307013-4-chris.packham@alliedtelesis.co.nz> <785368df-1881-e62e-6172-d902cee814a8@alliedtelesis.co.nz> <4ea0b16e-0cec-00db-c598-e0364a7edef8@alliedtelesis.co.nz> <9fc57052-5049-ed50-ca95-cfd1d0420dd9@alliedtelesis.co.nz> <20230606094855.1ab005eb@xps-13> <845924ba-d9bf-d0ec-e1f2-f721366f43c0@linaro.org> <20230606122812.411b223a@xps-13> <20230606125724.126a4685@xps-13> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Krzysztof, miquel.raynal@bootlin.com wrote on Tue, 6 Jun 2023 12:57:24 +0200: > Hi Krzysztof, >=20 > krzysztof.kozlowski@linaro.org wrote on Tue, 6 Jun 2023 12:40:45 +0200: >=20 > > On 06/06/2023 12:37, Krzysztof Kozlowski wrote: > > > On 06/06/2023 12:28, Miquel Raynal wrote: =20 > > >> Hi Krzysztof, > > >> > > >> krzysztof.kozlowski@linaro.org wrote on Tue, 6 Jun 2023 10:44:34 +02= 00: > > >> =20 > > >>> On 06/06/2023 09:48, Miquel Raynal wrote: =20 > > >>>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it (= otherwise it is harmless). > > >>>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $ref: /schemas/t= ypes.yaml#/definitions/flag > > >>>>>>>>>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 deprecated: true > > >>>>>>>>>> + > > >>>>>>>>>> +=C2=A0=C2=A0=C2=A0 additionalProperties: false =20 > > >>>>>>>>> unevaluatedProperties: false =20 > > >>>>>>>> It was hiding by '"^nand@[0-3]$":'. Should I move it here? = =20 > > >>>>>>> You cannot have both additionalProps and unevaluatedProps at th= e same > > >>>>>>> time, so we do not talk about same thing or this was never work= ing? =20 > > >>>>>> > > >>>>>> Hmm, I'm a little confused then. At various times I've been told= to=20 > > >>>>>> put 'additionalProperties: false' or 'unevaluatedProperties: fal= se'=20 > > >>>>>> (although never at the same time). I'm not sure when to use one = or the=20 > > >>>>>> other. > > >>>>>> > > >>>>>> From what I've been able to glean 'additionalProperties: true'=20 > > >>>>>> indicates that the node is expected to have child nodes defined = in a=20 > > >>>>>> different schema so I would have thought 'additionalProperties: = false'=20 > > >>>>>> would be appropriate for a schema covering a leaf node.=20 > > >>>>>> 'unevaluatedProperties: false' seems to enable stricter checking= which=20 > > >>>>>> makes sense when all the properties are described in the schema.= =20 > > >>>>> > > >>>>> So I think this might be the problem. If I look at qcom,nandc.yam= l or=20 > > >>>>> ingenic,nand.yaml which both have a partitions property in their= =20 > > >>>>> example. Neither have 'unevaluatedProperties: false' on the nand@= ...=20 > > >>>>> subnode. If I add it sure enough I start getting complaints about= the=20 > > >>>>> 'partitions' node being unexpected. =20 > > >>>> > > >>>> Sorry if that was unclear, I think the whole logic around the yaml > > >>>> files is to progressively constrain the descriptions, schema after > > >>>> schema. IOW, in the marvell binding you should set > > >>>> unevaluatedProperties: false for the NAND controller. What is insi= de > > >>>> (NAND chips, partition container, partition parsers, "mtd" propert= ies, > > >>>> etc) will be handled by other files. Of course you can constrain a= bit > > >>>> what can/cannot be used inside these subnodes, but I think you don= 't > > >>>> need to set unevaluatedProperties in these subnodes (the NAND chip= in > > >>>> this case, or even the partitions) because you already reference > > >>>> nand-controller.yaml which references nand-chip.yaml, mtd.yaml, > > >>>> partitions.yaml, etc. *they* will make the generic checks and hope= fully > > >>>> apply stricter checks, when deemed relevant. =20 > > >>> > > >>> No, neither nand-controller.yaml nor nand-chip.yaml limit the prope= rties > > >>> in this context, so each device schema must have unevaluatedPropert= ies: > > >>> false, for which I asked few emails ago. =20 > > >> > > >> The controller description shall be guarded by unevaluatedProperties: > > >> false, we agree. Do you mean the nand chip description in each nand > > >> controller binding should also include it at its own level? Because > > >> that is not what we enforced so far IIRC. I am totally fine doing so > > >> starting from now on if this is a new requirement (which makes sense= ). > > >> > > >> If yes, then it means we would need to list *all* the nand > > >> chip properties in each schema, which clearly involves a lot of > > >> duplication as you would need to define all types of partitions, > > >> partition parsers, generic properties, etc in order for the examples= to > > >> pass all the checks. Only the properties like pinctrl-* would not ne= ed > > >> to be listed I guess. =20 > > >=20 > > > Yes, this is what should be done. Each node should have either =20 > >=20 > > Eh, no, I responded in wrong part of message. My yes was for: > >=20 > > " Do you mean the nand chip description in each nand > > controller binding should also include it at its own level?" >=20 > Clear. >=20 > >=20 > > Now for actual paragraph: > >=20 > > "If yes, then it means we would need to list *all* the nand chip > > properties in each schema," > >=20 > > No, why? I don't understand. Use the same pattern as all other bindings, > > this is not special. Absolutely all have the same behavior, e.g. > > mentioned leds. You finish with unevaluatedProps and you're done, which > > is what I wrote here long, long time ago. >=20 > Maybe because so far we did not bother referencing another schema in > the NAND chip nodes? For your hint to work I guess we should have, in > each controller binding, something along: >=20 > patternProperties: > "^nand@[a-f0-9]$": > type: object > + $ref: nand-chip.yaml# > properties: >=20 > If yes, please ignore the series sent aside, I will work on it again > and send a v2. Actually I already see a problem, let's the ingenic,nand.yaml example. The goal, IIUC, is to do: patternProperties: "^nand@[a-f0-9]$": type: object + $ref: nand-chip.yaml properties: ... + unevaluatedProperties: false The example in this file uses a property, nand-on-flash-bbt, which is described inside nand-controller.yaml instead of nand-chip.yaml. Indeed, the former actually describes many properties which are a bit more controller related than chip related. With the above description, the example fails because nand-on-flash-bbt is not allowed (it is not listed in nand-chip.yaml). How would you proceed in this case? Maybe I could move all the NAND chip properties which are somehow related to NAND controllers (and defined in nand-controller.yaml) in a dedicated file and reference it from nand-chip.yaml? Any other idea is welcome. Thanks, Miqu=C3=A8l