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

[Rob Herring]

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