On 17/01/2023 16:58, Laurent Pinchart wrote:

Hi Krzysztof,

On Tue, Jan 17, 2023 at 04:42:51PM +0100, Krzysztof Kozlowski wrote:

quoted

On 17/01/2023 16:26, Laurent Pinchart wrote:

quoted

quoted

+
+          clock-lanes:
+            description: VIIF supports 1 clock line

s/line/lane/

quoted

+            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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel