On 17/01/2023 16:58, Laurent Pinchart wrote: > Hi Krzysztof, > > On Tue, Jan 17, 2023 at 04:42:51PM +0100, Krzysztof Kozlowski wrote: >> On 17/01/2023 16:26, Laurent Pinchart wrote: >>> >>>> + >>>> + clock-lanes: >>>> + description: VIIF supports 1 clock line >>> >>> s/line/lane/ >>> >>>> + const: 0 >>> >>> I would also add >>> >>> clock-noncontinuous: true >>> link-frequencies: true >>> >>> to indicate that the above two properties are used by this device. >> >> No, these are coming from other schema and there is never need to >> mention some property to indicate it is more used than other case. None >> of the bindings are created such way, so this should not be exception. > > There are some bindings that do so, but that may not be a good enough > reason, as there's a chance I wrote those myself :-) > > I would have sworn that at some point in the past the schema wouldn't > have validated the example with this omitted. I'm not sure if something > changed or if I got this wrong. You probably think about case when using additionalProperties:false, where one has to explicitly list all valid properties. But not for unevaluatedProperties:false. > > video-interfaces.yaml defines lots of properties applicable to > endpoints. For a given device, those properties should be required required: - foo > (easy, that's defined in the bindings), optional, by default (with unevaluatedProperties:false) or explicitly mention "foo: true (with additionalProperties:false) > or forbidden. How do foo: false (with unevaluatedProperties:false) or by default (with additionalProperties:false) > we differentiate between the latter two cases ? Best regards, Krzysztof
