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

[Bryan O'Donoghue]

On 15/10/2024 20:44, Rob Herring wrote:
> On Tue, Oct 15, 2024 at 02:28:06PM +0300, Laurent Pinchart wrote:
> > Hi Krzysztof,
> >
> > On Tue, Oct 15, 2024 at 08:11:18AM +0200, Krzysztof Kozlowski wrote:
> > > On 14/10/2024 22:29, Laurent Pinchart wrote:
> > > > 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.
>
> There are 3 options:
>
> - no $ref => additionalProperties

I interpret this to mean that omitting 
additionalProperties/unevaluatedProperties is logically the same as 
having additionalProperties as you will then need to list the properties 
explicitly.

> - has a $ref:
>      - additionalProperties and list ref-ed properties
>      - unevaluatedProperties and don't list ref-ed properties
>
> I do debate (with myself) that that is too complicated as many don't
> understand the difference. 


We could go back to always using
> additionalProperties which is what we had before unevaluatedProperties
> was added. The other option is always use unevaluatedProperties. 2
> things have stopped me from going that route. I don't care to fix
> 'additionalProperties' treewide which would be necessary to implement a
> meta-schema or check that unevaluatedProperties is used. It's not
> something I want to manually check in reviews. The other reason is just
> to not change what the rules are again.

Right so I received feedback to change link-frequencies if I recall. I 
thought I had been very-clever (tm) by copying an upstream source and 
when I received feedback to change assumed the upstream source I had 
copied had bit-rot w/r/t the current preferred way.

Some additional discussion shows there really isn't a preferred way at 
present.

Is there a place to meaningfully document that conclusion instead both 
for reviewers and implementers ?

Should I already know the answer to that question ?

---
bod