On Mon, Apr 06, 2020 at 02:28:56PM +0300, Laurent Pinchart wrote: > > > + > > > + clock-names: > > > + items: > > > + - const: iahb > > > + - const: isfr > > > + > > > + interrupts: true > > > + > > > + ports: > > > + type: object > > > + description: | > > > + This device has three video ports. Their connections are modelled using the > > > + OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. > > > + Each port shall have a single endpoint. > > > + > > > + properties: > > > + '#address-cells': > > > + const: 1 > > > + > > > + '#size-cells': > > > + const: 0 > > > + > > > + port@0: > > > + type: object > > > + description: Parallel RGB input port > > > + > > > + port@1: > > > + type: object > > > + description: HDMI output port > > > + > > > + port@2: > > > + type: object > > > + description: Sound input port > > > + > > > + required: > > > + - port@0 > > > + - port@1 > > > + - port@2 > > > + > > > + additionalProperties: false > > > + > > > + power-domains: > > > + maxItems: 1 > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - clocks > > > + - clock-names > > > + - interrupts > > > + - ports > > > + > > > +additionalProperties: false > > > > In the case where you have some kind of generic schema and then a more > > specific one like you have here, unevaluatedProperties make more sense > > that additionalProperties. > > > > additionalProperties checks that there are no extra properties on the > > current schema, which is a problem here since you have to duplicate > > the entire list of properties found in the generic schema, while > > unevaluatedProperties checks that there are no extra properties in the > > entire set of all schemas that apply to this node. > > > > This way, you can just put what is different from the generic schema, > > and you don't have to keep it in sync. > > > > It's a feature that has been added in the spec of the schemas that > > went on right after the one we support in the tools, so for now the > > kernel meta-schemas only allows that property to be there (just like > > deprecated) but won't do anything. > > > > This should be fixed quite soon however, the library we depend on > > has started to work on that spec apparently. > > Should I postpone this series until support for unevaluatedProperties is > available, to be able to test this ? There's no need to wait, just put it in and it will eventually be checked. And the time between now and then won't be worse than the current situation of not checking anything at all anyway :) Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
