linux-kernel - Re: [PATCH 01/13] dt-bindings: soc: mobileye: set `#clock-cells = <1>` for all compatibles

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] [day] [month] [year] [list]

Message-ID: <20241105133323.GA3064907-robh@kernel.org>
Date: Tue, 5 Nov 2024 07:33:23 -0600
From: Rob Herring <robh@...nel.org>
To: Théo Lebrun <theo.lebrun@...tlin.com>
Cc: Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
	Grégory Clement <gregory.clement@...tlin.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	linux-mips@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH 01/13] dt-bindings: soc: mobileye: set `#clock-cells =
 <1>` for all compatibles

On Mon, Nov 04, 2024 at 05:46:10PM +0100, Théo Lebrun wrote:
> On Mon Nov 4, 2024 at 4:37 PM CET, Rob Herring wrote:
> > On Thu, Oct 31, 2024 at 04:52:51PM +0100, Théo Lebrun wrote:
> > > Some compatibles expose a single clock. For those, we used to let them
> > > using `#clock-cells = <0>` (ie <&olb> reference rather than <&olb 0>).
> > > 
> > > Switch away from that: enforce a cell for all compatibles. This is more
> > > straight forward, and avoids devicetree changes whenever a compatible
> > > goes from exposing a single clock to multiple ones.
> >
> > Your reasoning is flawed. Changing #clock-cells is an ABI break. So you 
> > should only be changing this if it was just wrong. And if it's not wrong 
> > in some cases, you shouldn't be changing those. The h/w either has 1 
> > clock or multiple and #clocks-cells should match.
> 
> I see your reasoning, and I agree that changing #clock-cells is an ABI
> break. However, there are two things to take into account:
> 
>  - We do not (yet?) have an omniscient view of the hardware. We do not
>    know what every single register in those memory regions do.
> 
>    Some clocks might be lurking in the shadows, especially as we don't
>    support many HW capabilities yet.
> 
>  - The earlier the better. If we discover later down the road that,
>    indeed, some more clocks were hiding, we'll have to do an ABI break.
> 
>    At that point, some people might actually be using the platform.
>    Seeing what we currently have supported upstream versus the amount
>    of HW blocks available in the SoC, I cannot imagine anyone using the
>    platform with an upstream kernel.
> 
> So the choice is:
>  - potential ABI break in the future, once people use the platform, or,
>  - guaranteed ABI break now, when no one is using it.
> 
> I pick option two! Do you agree with the thought process?

Ultimately, it is up to you and the maintainers for the platform to 
decide. I only ask that ABI breaks are called out as ABI breaks with 
reasoning given for the ABI break.

I had no clue whether you have access to RTL or are reverse engineering 
this or something in between.

Please summarize the above explanation for the commit msg.

Rob