On 06/06/2023 09:48, Miquel Raynal wrote: >>>>>>> + 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
