lkml.org 
[lkml]   [2022]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 2/3] dt-bindings: net: sun8i-emac: Fix snps,dwmac.yaml inheritance
On Wed, Nov 30, 2022 at 9:45 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Nov 26, 2022 at 03:48:33PM +0100, Krzysztof Kozlowski wrote:
> > On 26/11/2022 15:28, Andre Przywara wrote:
> > > On Sat, 26 Nov 2022 14:26:25 +0100
> > > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> > >
> > > Hi,
> > >
> > >> On 25/11/2022 21:20, Samuel Holland wrote:
> > >>> The sun8i-emac binding extends snps,dwmac.yaml, and should accept all
> > >>> properties defined there, including "mdio", "resets", and "reset-names".
> > >>> However, validation currently fails for these properties because the
> > >>
> > >> validation does not fail:
> > >> make dt_binding_check -> no problems
> > >>
> > >> Maybe you meant that DTS do not pass dtbs_check?
> > >
> > > Yes, that's what he meant: If a board actually doesn't have Ethernet
> > > configured, dt-validate complains. I saw this before, but didn't find
> > > any solution.
> > > An example is: $ dt-validate ... sun50i-a64-pinephone-1.2.dtb
> > > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dtb:
> > > ethernet@1c30000: Unevaluated properties are not allowed ('resets', 'reset-names', 'mdio' were unexpected)
> > > From schema: Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
> > >
> > > Why exactly is beyond me, but this patch removes this message.
> >
> > I don't think this should be fixed like this. That's the problem of
> > dtschema (not ignoring fully disabled nodes) and such patch only moves
> > from one correct syntax to another correct syntax, which fixes dtschema
> > problem, but changes nothing here.
>
> Humm, it looks to me like the 'phy-mode' required in snps,dwmac.yaml
> causes the problem, but I can't get a minimized example to fail.
> Something in 'required' shouldn't matter. Definitely seems like an issue
> in the jsonschema package. I'll keep looking at it.

TLDR: A fix in dtschema for this will be in place soon.

I've simplified this down to:
{
"$schema": "https://json-schema.org/draft/2019-09/schema",

"unevaluatedProperties": false,
"allOf":[
{
"properties": {
"foo": true,
"bar": true
},
"required": [ "foo" ]
}
]
}

An instance { "bar": 1 } will fail due to the 'required' failing. When
you have a subschema (what's under 'allOf'), then it all has to pass
to be 'evaluated'. This seems inconsistent to me, but the json-schema
folks say it is operating as intended.

I've got 2 possible fixes. One is to just ignore unevaluatedProperties
errors on disabled nodes like is already done for 'required'. This
means disabled nodes can have any unknown property or child node added
which isn't great. The other way overrides 'required' validation to
always pass on disabled nodes. This would be better, but there are
some exceptions we need to still fail. 'oneOf' with N entries of
'required' to say 1 of N properties must be present for example.
Excluding each one of these cases will be fragile, so probably going
with the first fix.

Rob

\
 
 \ /
  Last update: 2022-12-01 19:12    [W:0.078 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site