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

[Krzysztof Kozlowski]

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 at ... 
>> 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