| 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
| ||
|
Message-ID: <CAMuHMdVObafuLMBOt=atHJtBBcZ8s0C21Ep2juRE0XPih+iHBA@mail.gmail.com>
Date: Fri, 30 Jan 2026 17:48:59 +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 17:25, Ovidiu Panait
<ovidiu.panait.rb@...esas.com> wrote:
> > 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 -> ...
I was already afraid so...
OK, then please just add comments like:
@@ -289,9 +289,9 @@ versa3: clock-generator@69 {
reg = <0x69>;
clocks = <&x1>;
#clock-cells = <1>;
- assigned-clocks = <&versa3 0>,
+ assigned-clocks = <&versa3 0>, /* quextal */
<&versa3 1>,
- <&versa3 2>,
+ <&versa3 2>, /* rtxin_clk */
<&versa3 3>,
<&versa3 4>,
<&versa3 5>;
Any others needed?
Thanks for testing!
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
Powered by blists - more mailing lists