Quoting mkrishn@xxxxxxxxxxxxxx (2021-03-30 02:22:29) > On 2021-03-29 08:49, Stephen Boyd wrote: > > > > Does that matter? I was wondering about that and so I peeked at the > > qcom pinctrl binding and it seems to follow a similar design but > > doesn't > > have unevaluatedProperties: false. Instead it has additionalProperies: > > false. See qcom,sc8180x-pinctrl.yaml for an example. So did you try it > > or does something say you can't do this? > > Hi Stephen, > I had tried the same thing in one of my initial patches and I got a > comment from Rob that we have to use unevaluatedProperties when we are > referring another > file(https://patchwork.kernel.org/project/linux-arm-msm/patch/1589868421-30062-1-git-send-email-mkrishn@xxxxxxxxxxxxxx/) > In latest dt-schema tool, we will get error if we try to change it to > additionalProperties: false. > For example, in this patch "#clock-cells' and '#phy-cells' are mentioned > in dsi-phy-common.yaml and I am referring this file in > dsi-phy-10nm.yaml. If I add > additionalProperties: false instead of unevaluatedProperties: false, I > will get the error mentioned below. > > I checked qcom,sc8180x-pinctrl.yaml that you had mentioned in the > comment and this file is compiling without any issues even though it is > using additionalProperties: false. But I see that the properties > mentioned in the reference file (in this case, qcom,tlmm-common.yaml) > are again declared in the main file qcom,sc8180x-pinctrl.yaml even > though these are mentioned as required properties in the common yaml > file. If I remove these properties from qcom,sc8180x-pinctrl.yaml, I can > see the same error that I am getting for my file also if > additionalProperties are used. If I follow the same approach , ie define > the properties again in dsi-phy-10nm.yaml and add additionalProperties: > false, I dont see any errors during check (working change mentioned > below). Should I make this change for all the files? Honestly I don't know. Can you resend this series and Cc <robh+dt@xxxxxxxxxx> and <devicetree@xxxxxxxxxxxxxxx>? You don't have to change this part, but it would be good to call out that you decided to stick with unevaluatedProperties vs. additionalProperties somewhere in the changelog or commit text.
