Re: [PATCH v8 3/3] dt-bindings: mtd: marvell-nand: Convert to YAML DT scheme

On 06/06/2023 09:48, Miquel Raynal wrote:

quoted

quoted

quoted

quoted

quoted

quoted

+          it (otherwise it is harmless).
+        $ref: /schemas/types.yaml#/definitions/flag
+        deprecated: true
+
+    additionalProperties: false  

unevaluatedProperties: false  

It was hiding by '"^nand@[0-3]$":'. Should I move it here?  

You cannot have both additionalProps and unevaluatedProps at the same
time, so we do not talk about same thing or this was never working?  

Hmm, I'm a little confused then. At various times I've been told to 
put 'additionalProperties: false' or 'unevaluatedProperties: false' 
(although never at the same time). I'm not sure when to use one or the 
other.

From what I've been able to glean 'additionalProperties: true' 
indicates that the node is expected to have child nodes defined in a 
different schema so I would have thought 'additionalProperties: false' 
would be appropriate for a schema covering a leaf node. 
'unevaluatedProperties: false' seems to enable stricter checking which 
makes sense when all the properties are described in the schema.  

So I think this might be the problem. If I look at qcom,nandc.yaml or 
ingenic,nand.yaml which both have a partitions property in their 
example. Neither have 'unevaluatedProperties: false' on the nand@... 
subnode. If I add it sure enough I start getting complaints about the 
'partitions' node being unexpected.

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 inside
(NAND chips, partition container, partition parsers, "mtd" properties,
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 hopefully
apply stricter checks, when deemed relevant.

No, neither nand-controller.yaml nor nand-chip.yaml limit the properties
in this context, so each device schema must have unevaluatedProperties:
false, for which I asked few emails ago.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel