On 16/03/2026 14:53, Laurent Pinchart wrote:

Hello Krzysztof,

Thank you for the patch.

On Mon, Mar 16, 2026 at 02:45:34PM +0100, Krzysztof Kozlowski wrote:

quoted

The "endpoint" node references video-interfaces.yaml schema with
"unevaluatedProperties: false" which means that all properties from
referenced schema apply.  Listing some of them with ": true" is simply
redundant and does not make this code easier to read.

I think you know my opinion on this topic. I believe we would be better
off by turning "unevaluatedProperties: false" into
"additionalProperties: false" here, and keeping the list of applicable
properties. It brings value to device tree authors by telling which
properties are applicable to the device at hand. For instance ... (see
below)

(let me trim)

quoted

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
index 2d7937a372a2..7a05a1eda58d 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml

@@ -51,9 +51,6 @@ properties:
         $ref: /schemas/media/video-interfaces.yaml#
         unevaluatedProperties: false
 
-        properties:
-          clock-noncontinuous: true
-

... Without this, an integrator will need to dive into driver code to
know if non-continuous clock is usable for the device.

I see. Our usual interpretation of common schema, expressed by @Rob in
few places, that eventually all properties might be applicable. This
applies especially for ABI tied to the core Linux specifics, e.g.
rotation and orientation from video-interface-devices.yaml.

Absolutely every sensor can be mounted rotated, therefore every binding
referencing video-interface-devices should allow it, even if driver is
not using it. Because basically that's the ABI we want to define for
each sensor, thus each binding referencing common schema should have
"unevaluatedProps: true" without listing them.

Similarly touchscreen.yaml.

OTOH, second option, properties which are strictly hardware, e.g. name
of power supply or whether clock has or has not non-continuous mode,
should be allowed only when they match the hardware. Such bindings
should use "additionalProperties: false" so the hardware description is
constrained/fixed/specific.

The only exception is trivial-devices.

To the point:

1. We should not have another exception of listing hardware properties
and allowing them for every device, even if device does not have.

2. What's more, you propose unwritten coding style
(unevaluatedProps:false with listing properties when you want to
indicate hardware capability) which will be very difficult to implement.
I doubt that existing bindings, except a few, follow such approach. I
doubt we will remember this... And it already spreads to new bindings
when I ask to remove redundant "foo: true" properties.

3. These sensor bindings should follow only one of mentioned earlier
options - additionalProps or unevaluatedProps - because either these are
hardware properties or this is generic kernel ABI which everyone
will/could use.

Best regards,
Krzysztof