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: <0c4d199a-ed74-4d44-a715-ceb498898ddc@kernel.org>
Date: Tue, 15 Oct 2024 13:51:43 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...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 13:28, 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.
>>>>
>>>> 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:
>>
>> Why is this a problem? Why is this a problem here, but not in other
>> subsystems having exactly the same case?
> 
> I won't talk for other subsystems, but I can say I see value in
> explicitly expressing what properties are valid for a device in DT
> bindings both to inform DT authors and to perform validation on DT
> sources. That's the whole point of YAML schemas, and I can't see a good
> reason not to use the tooling we have developed when it has an easy way
> to do the job.

I understand. The benefit, which you see, comes with complexity of the
binding and need of listing properties.

We do not enforce such rules (narrowing common schema in very strict
way) in other subsystems, maybe with exception of input and touchscreen
devices, but there common schema is quite big. And DT maintainers
suggested to drop such code even for these, BTW.

Best regards,
Krzysztof