[PATCH 2/2] media: dt-bindings: Use additionalProperties: false for endpoint: properties:

[Laurent Pinchart]

On Mon, Oct 14, 2024 at 10:47:31AM +0200, Krzysztof Kozlowski wrote:
> On 14/10/2024 10:31, Bryan O'Donoghue wrote:
> > On 14/10/2024 08:45, Krzysztof Kozlowski wrote:
> >> I do not understand the reasoning behind this change at all. I don't
> >> think DT maintainers ever suggested it (in fact, rather opposite:
> >> suggested using unevaluatedProps) and I think is not a consensus of any
> >> talks.
> > 
> > No there is not but then, how do you give consistent feedback except 
> > proposing something to be a baseline.
> > 
> > On the one hand you have upstream additionalProperties: false and 
> > unevaluatedProperites: false - it'd be better to have a consistent 
> > message on which is to be used.
> 
> Well, I am afraid that push towards additionalProps will lead to grow
> common schema (video-interface-devices or video-interfaces) into huge
> one-fit-all binding. And that's not good.
> 
> If a common binding for a group of devices encourages you to list its
> subset, then it is not that common.
> 
> Solution is to fix that, e.g. split it per classes of devices.

I think splitting large schemas per class is a good idea, but the
problem will still exist. For instance, if we were to move the
CSI-2-specific properties to a separate schema, that schema would define
clock-lanes, data-lanes and clock-noncontinuous. The clock-lanes and
clock-noncontinuous properties do not apply to every device, how would
we then handle that ? I see three options:

- Use "additionalProperties: false" and explicitly list the properties that apply
  to the device with "$prop: true". This is what this series does.

- Use "unevaluatedProperites: false" and explicitly list the properties
  that do not apply to the device with "$prop: false". The drawback is
  that any property being added to the common schema will require
  modifications to all bindings that use the schema.

- Use "unevaluatedProperites: false" and don't list any property with
  "$prop: false". This is what is being done today in many bindings. The
  drawback is that device tree sources that specify invalid properties
  for the device will validate.

Among those options, my preference goes to the first one. It catches the
most issues in device tree sources, while not having the drawback of the
second option. It requires explicitly listing the valid properties, but
I don't consider that as a drawback, I think it's actually a good thing
as it clearly shows to the developers which properties are valid.

Are there other options I haven't considered ?

> Or don't care and use unevaluatedProps because it makes people's life
> easier and is still correct. If it is not correct, then this should be
> used as an argument.

-- 
Regards,

Laurent Pinchart