[PATCH] dt-bindings: display: panel: use spi-peripheral-props.yaml

[Rob Herring]

On Tue, Oct 4, 2022 at 8:17 AM Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> Hi Krzysztof,
>
> On Tue, Oct 04, 2022 at 03:10:29PM +0200, Krzysztof Kozlowski wrote:
> > On 04/10/2022 15:03, Laurent Pinchart wrote:
> > > On Tue, Oct 04, 2022 at 02:09:07PM +0200, Krzysztof Kozlowski wrote:
> > >> For devices connectable by SPI bus (e.g. already using
> > >> "spi-max-frequency" property), reference the "spi-peripheral-props.yaml"
> > >> schema to allow using all SPI device properties, even these which device
> > >> bindings author did not tried yet.
> > >
> > > Isn't this done implicitly by spi-controller.yaml ? SPI devices that are
> > > children of an SPI controller should match the patternProperties
> > > "^.*@[0-9a-f]+$" in that file, which has a $ref: spi-peripheral-props.yaml.
> > > Is there something I'm missing ?
> >
> > You are correct about one side of this - SPI controller bindings.
> > However these schemas here have clear: additional/unevaluatedProperties:
> > false, thus when they find DTS like:
> > panel at xxx {
> >   compatible = "one of these spi panels";
> >   ...
> >   spi-cs-high;
> >   spi-rx-delay-us = <50>;
> >   ... and some more from specific controllers
> > }
> >
> > you will get errors, because the panel schema does not allow them.
> >
> > The bindings were done (some time ago) in such way, that they require
> > that both SPI controller and SPI device reference spi-props.
>
> You're absolutely right that additionalProperties needs to be replaced
> by unevaluatedProperties. Can the additions of $ref be dropped, or is
> that needed too ?

unevaluatedProperties doesn't work with child node schemas (from one
or both schemas). This is because the schemas are applied
independently and can't 'see' each other. The spi-controller.yaml
schema is applied to the SPI bus node and SPI peripheral schemas are
applied to SPI device nodes. This means that child node schemas have
to either be complete or only list properties which will be listed in
the complete schema for the child nodes. For example, 'reg' has to be
listed anyways to define how many entries. This is also why we need a
ref at each level in the graph binding anytime there are additional
properties defined.

Rob