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
