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: <CAMuHMdUwsC96cnsZqkV63hnG=C86G5ymScY3qnLR9v830D4m4Q@mail.gmail.com>
Date: Fri, 30 Jan 2026 16:14:42 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Ovidiu Panait <ovidiu.panait.rb@...esas.com>
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 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?
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