All of lore.kernel.org
 help / color / mirror / Atom feed
* dt-validate issues with the oneOf/$ref/incomplete node
@ 2022-08-22 20:03 Dmitry Baryshkov
  2022-08-23 19:03 ` Rob Herring
  0 siblings, 1 reply; 2+ messages in thread
From: Dmitry Baryshkov @ 2022-08-22 20:03 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

Hi,

Short story:

If the dt schema file has a property with using oneOf/anyOf of several 
$ref references and the corresponding device node is incomplete and has 
status = "disabled", then the dt-validate would still validate the node 
against these schemas (and fail the validation as the node is incomplete).


Long story:


For quite a while I have been stumbling with the issue during 
refactoring the display/msm/mdss schema.

The schema had the following part:

patternProperties:
   "^dsi-phy@[1-9a-f][0-9a-f]*$":
     oneOf:
       - $ref: dsi-phy-28nm.yaml#
       - $ref: dsi-phy-20nm.yaml#
       - $ref: dsi-phy-14nm.yaml#
       - $ref: dsi-phy-10nm.yaml#
       - $ref: dsi-phy-7nm.yaml#

Validating existing DT files against just 
'DT_SCHEMA_FILES=display/msm/mdss' would work w/o errors. Validating 
against 'DT_SCHEMA_FILES=display/msm/dsi' would also validate w/o any 
issues. However specifying 'DT_SCHEMA_FILES=display/msm' (thus enabling 
both mdss.yaml and dsi-phy-*.yaml) would cause a long stream of 
"mdss@ae00000: dsi-phy@ae96400: 'oneOf' conditional failed, one must be 
fixed:" errors.

For quite a while I failed to understand what was causing the issue 
until I found that the errors are reported against the _disabled_ device 
nodes which miss e.g. several -supply nodes. If I added the 
corresponding missing supplies (or removed the requirement to have the 
supply from corresponding .yaml) then the file would validate against 
mdss.yaml + dsi*yaml combo.

Thus I suppose something goes wrong with the validation of disabled 
nodes against oneOf conditionals.

-- 
With best wishes
Dmitry

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: dt-validate issues with the oneOf/$ref/incomplete node
  2022-08-22 20:03 dt-validate issues with the oneOf/$ref/incomplete node Dmitry Baryshkov
@ 2022-08-23 19:03 ` Rob Herring
  0 siblings, 0 replies; 2+ messages in thread
From: Rob Herring @ 2022-08-23 19:03 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Krzysztof Kozlowski,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Aug 22, 2022 at 3:03 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> Hi,
>
> Short story:
>
> If the dt schema file has a property with using oneOf/anyOf of several
> $ref references and the corresponding device node is incomplete and has
> status = "disabled", then the dt-validate would still validate the node
> against these schemas (and fail the validation as the node is incomplete).

For disabled nodes, we just try to filter out 'required' errors. I
think that's not handled here because there are multiple required
errors and we just see the 'oneOf' error.

>
>
> Long story:
>
>
> For quite a while I have been stumbling with the issue during
> refactoring the display/msm/mdss schema.
>
> The schema had the following part:
>
> patternProperties:
>    "^dsi-phy@[1-9a-f][0-9a-f]*$":
>      oneOf:
>        - $ref: dsi-phy-28nm.yaml#
>        - $ref: dsi-phy-20nm.yaml#
>        - $ref: dsi-phy-14nm.yaml#
>        - $ref: dsi-phy-10nm.yaml#
>        - $ref: dsi-phy-7nm.yaml#

The easiest solution here may be to just drop this. It is not a common
pattern. It does serve some purpose in that the node will have one of
the right compatibles, but otherwise this causes the schema to be
applied twice.


> Validating existing DT files against just
> 'DT_SCHEMA_FILES=display/msm/mdss' would work w/o errors. Validating
> against 'DT_SCHEMA_FILES=display/msm/dsi' would also validate w/o any
> issues. However specifying 'DT_SCHEMA_FILES=display/msm' (thus enabling
> both mdss.yaml and dsi-phy-*.yaml) would cause a long stream of
> "mdss@ae00000: dsi-phy@ae96400: 'oneOf' conditional failed, one must be
> fixed:" errors.

I would expect the oneOf error in all cases the schema with the the
oneOf is included by DT_SCHEMA_FILES value. Is that not the case in
the first case?

>
> For quite a while I failed to understand what was causing the issue
> until I found that the errors are reported against the _disabled_ device
> nodes which miss e.g. several -supply nodes. If I added the
> corresponding missing supplies (or removed the requirement to have the
> supply from corresponding .yaml) then the file would validate against
> mdss.yaml + dsi*yaml combo.
>
> Thus I suppose something goes wrong with the validation of disabled
> nodes against oneOf conditionals.
>
> --
> With best wishes
> Dmitry

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-08-23 19:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-22 20:03 dt-validate issues with the oneOf/$ref/incomplete node Dmitry Baryshkov
2022-08-23 19:03 ` Rob Herring

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.