Re: [PATCH v3 07/12] arm64: dts: renesas: r9a08g045: Add VBATTB node

[Stephen Boyd <sboyd@kernel.org>]

Quoting Geert Uytterhoeven (2024-09-09 05:11:03)
> Hi Stephen,
> 
> On Sat, Sep 7, 2024 at 1:01 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > Quoting Geert Uytterhoeven (2024-09-06 00:28:38)
> > >
> > > My main objections are that (1) this approach is different than the one used
> > > for all other external clock inputs on Renesas SoCs, and (2) this requires
> > > duplicating part of the clocks property in all board DTS files.
> >
> > Can 'clock-ranges' be used here? Leave the cell as null in the SoC dtsi
> > file and then fill it in with clocks property at the parent node. I
> > think you'd have to use clock-names for this though.
> 
> "clock-ranges" does not seem to be well-documented...

Yeah, I wasn't aware of it for years!

> 
> IUIC, your suggestion is to:
>   1. Add "clock-ranges" to the /soc subnode,
>   2. Completely leave out the "rtx" clock from the clocks property
>      of the vbattb@1005c000 node,
>   3. Add the following to the board DTS:
> 
>         &soc {
>                 clocks = <&vbattb_xtal>;
>                 clock-names = "rtx";
>         };
> 
> Then, when resolving "rtx" for the vbattb@1005c000 node,
> of_parse_clkspec() would iterate up and find the proper vbattb_xtal.
> Is that correct? And probably that should be done for other external
> clock inputs as well?

Sounds about right.

> 
> Still, it looks a bit complicated and un-intuitive. And what about
> e.g. carrier boards with a SoM, where some clocks are provided by
> the SoM, and some by the carrier? In that case you still have to
> override the clock and clock-names properties in the carrier .dts,
> thus duplicating all clocks provided by the SoM.

This is the same case as the board wanting to override the soc node?
When it's a SoM is there a node for the SoM? Is the clock on the SoM?
Does this case exist? Hopefully this isn't a straw man.

> 
> So I prefer the original approach, like is done for all other external
> SoC clock inputs on Renesas SoCs.
> 

Sure. I'm just suggesting to follow the preferred approach by DT
maintainers. I don't feel strongly either way and I'm not the SoC
maintainer so feel free to do what you want.