Hi Stephen, On Mon, Sep 9, 2024 at 11:18 PM Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > Quoting Geert Uytterhoeven (2024-09-09 05:11:03) > > On Sat, Sep 7, 2024 at 1:01 AM Stephen Boyd <sboyd@xxxxxxxxxx> 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? Yes, but more complicated, > 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. E.g. the White Hawk CPU board[1] contains extal_clk, extalr_clk, and scif_clk, so it would need something like: &soc { clocks = <&extal_clk>, <&extalr_clk>, <&scif_clk>; clocks-names = "extal", "extalr", "scif"; }; The White Hawk Break-Out board[2] contains can_clk, so it would need to append that, by overriding (duplicate + append): &soc { clocks = <&extal_clk>, <&extalr_clk>, <&scif_clk>, <&can_clk>; clocks-names = "extal", "extalr", "scif", "can"; }; Currently, [1] does: &extal_clk { clock-frequency = <16666666>; }; &extalr_clk { clock-frequency = <32768>; }; &scif_clk { clock-frequency = <24000000>; }; And [2] does: &can_clk { clock-frequency = <40000000>; }; [1] arch/arm64/boot/dts/renesas/white-hawk-cpu-common.dtsi: [2] arch/arm64/boot/dts/renesas/white-hawk-common.dtsi Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds