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:
 <TY7P301MB1984CB3A92C79442592B045DD39FA@TY7P301MB1984.JPNP301.PROD.OUTLOOK.COM>
Date: Fri, 30 Jan 2026 13:43:07 +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 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?

Thanks!
Ovidiu


> > +                                      <22579200>,
> > +                                      <100000000>,
> > +                                      <100000000>;
> > +       };
> >  };
> >
> >  &mdio0 {
> 
> 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