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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1efe72f0-6777-4057-8c5d-47e891ae1b0d@linaro.org>
Date: Tue, 15 Oct 2024 23:45:02 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Rob Herring <robh@...nel.org>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Dave Stevenson <dave.stevenson@...pberrypi.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>, Shawn Guo
 <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Martin Kepplinger <martink@...teo.de>,
 Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
 "Paul J. Murphy" <paul.j.murphy@...el.com>,
 Daniele Alessandrelli <daniele.alessandrelli@...el.com>,
 Tommaso Merciai <tomm.merciai@...il.com>,
 Martin Hecht <martin.hecht@...et.eu>, Zhi Mao <zhi.mao@...iatek.com>,
 Alain Volmat <alain.volmat@...s.st.com>,
 Mikhail Rudenko <mike.rudenko@...il.com>,
 Ricardo Ribalda <ribalda@...nel.org>,
 Kieran Bingham <kieran.bingham@...asonboard.com>,
 Umang Jain <umang.jain@...asonboard.com>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Dongchun Zhu <dongchun.zhu@...iatek.com>,
 Quentin Schulz <quentin.schulz@...obroma-systems.com>,
 Todor Tomov <todor.too@...il.com>, linux-media@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] media: dt-bindings: Use additionalProperties: false
 for endpoint: properties:

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