linux-kernel - RE: [PATCH v2 4/5] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add versa3 clock generator node

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] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <TY7P301MB1984FB85250A9B18B5F981F5D39FA@TY7P301MB1984.JPNP301.PROD.OUTLOOK.COM>
Date: Fri, 30 Jan 2026 16:25:30 +0000
From: Ovidiu Panait <ovidiu.panait.rb@...esas.com>
To: geert <geert@...ux-m68k.org>
CC: magnus.damm <magnus.damm@...il.com>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "mturquette@...libre.com" <mturquette@...libre.com>,
	"sboyd@...nel.org" <sboyd@...nel.org>, Biju Das <biju.das.jz@...renesas.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: RE: [PATCH v2 4/5] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Add
 versa3 clock generator node

Hi Geert,

> 
> Hi Ovidiu,
> 
> On Fri, 30 Jan 2026 at 14:43, Ovidiu Panait
> <ovidiu.panait.rb@...esas.com> wrote:
> > > On Tue, 20 Jan 2026 at 16:06, Ovidiu Panait
> > > <ovidiu.panait.rb@...esas.com> wrote:
> > > > Add versa3 clock generator node. It provides clocks for the RTC,
> PCIe
> > > > and audio devices.
> > > >
> > > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@...esas.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > > > +++ b/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > > > @@ -108,6 +108,12 @@ vqmmc_sdhi1: regulator-vccq-sdhi1 {
> > > >                 states = <3300000 0>, <1800000 1>;
> > > >         };
> > > >
> > > > +       x1: x1-clock {
> > > > +               compatible = "fixed-clock";
> > > > +               #clock-cells = <0>;
> > > > +               clock-frequency = <24000000>;
> > > > +       };
> > > > +
> > > >         /* 32.768kHz crystal */
> > > >         x6: x6-clock {
> > > >                 compatible = "fixed-clock";
> > > > @@ -277,6 +283,25 @@ raa215300: pmic@12 {
> > > >                 clocks = <&x6>;
> > > >                 clock-names = "xin";
> > > >         };
> > > > +
> > > > +       versa3: clock-generator@69 {
> > > > +               compatible = "renesas,5l35023";
> > > > +               reg = <0x69>;
> > > > +               clocks = <&x1>;
> > > > +               #clock-cells = <1>;
> > > > +               assigned-clocks = <&versa3 0>,
> > > > +                                 <&versa3 1>,
> > > > +                                 <&versa3 2>,
> > > > +                                 <&versa3 3>,
> > > > +                                 <&versa3 4>,
> > > > +                                 <&versa3 5>;
> > > > +               assigned-clock-rates = <24000000>,
> > >
> > > Shouldn't (at least) qextal_clk and
> > >
> > > > +                                      <24576000>,
> > > > +                                      <32768>,
> > >
> > > rtxin_clk be overridden to point to the corresponding versa3 outputs?
> > > Same comment for [PATCH v2 5/5].
> > >
> >
> > I tried implementing this by overriding qextal_clk and rtxin_clk with
> > fixed-factor-clock nodes that reference the versa3 outputs as parents:
> >
> > --- a/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > +++ b/arch/arm64/boot/dts/renesas/r9a09g057h44-rzv2h-evk.dts
> > @@ -504,7 +504,11 @@ io {
> >  };
> > ·
> >  &qextal_clk {
> > -       clock-frequency = <24000000>;
> > +       compatible = "fixed-factor-clock";
> > +       clocks = <&versa3 0>;
> > +       #clock-cells = <0>;
> > +       clock-mult = <1>;
> > +       clock-div = <1>;
> >  };
> > ·
> >  &rtc {
> > @@ -512,7 +516,11 @@ &rtc {
> >  };
> > ·
> >  &rtxin_clk {
> > -       clock-frequency = <32768>;
> > +       compatible = "fixed-factor-clock";
> > +       clocks = <&versa3 2>;
> > +       #clock-cells = <0>;
> > +       clock-mult = <1>;
> > +       clock-div = <1>;
> >  };
> >
> > However, this breaks the boot. The problem seems to be probe
> > ordering:
> > 1. fixed-factor-clock uses CLK_OF_DECLARE, so it registers very early
> > 2. At that point, versa3 clocks are not yet available (since versa3 is
> > an I2C device, it is probed much later)
> > 3. The clock framework registers the fixed-factor-clock with rate = 0
> > 4. Consumers (RTC, timers, etc) probe and see rate = 0, causing failures
> >
> > I'm also concerned that if qextal_clk (the main SoC clock) depends on
> > versa3, nearly everything would need to defer until the I2C subsystem
> > and versa3 driver are ready.
> >
> > Could you please provide any suggestions on how to handle this?
> 
> I meant to override the references to qextal_clk and rtxin_clk, i.e.
> 
>     &cpg {
>             clocks = <&audio_extal_clk>, <&versa3 2>, <&versa3 0>;
>     };
> 
> However, that could still delay everything, in which case we should
> just document the routing in the DTS using comments.
> 
> Can you please give it a try?

With this change, the board doesn't boot at all, no output on the
serial console.

I think with this we are introducing the following circular clk
dependency chain:

    cpg -> versa3 -> i2c -> cpg -> ...

Thanks,
Ovidiu

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-
> m68k.org
> 
> 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