[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWxSGn7Hohn2oU1i2eiO+LOSHm7gXCX5OByvSgXm+00SA@mail.gmail.com>
Date: Fri, 12 Aug 2022 11:32:34 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Rob Herring <robh@...nel.org>
Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
linux-clk <linux-clk@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Biju Das <biju.das.jz@...renesas.com>,
"Lad, Prabhakar" <prabhakar.csengg@...il.com>
Subject: Re: [PATCH] dt-bindings: clock: renesas,rzg2l: Document RZ/Five SoC
Hi Rob,
On Fri, Aug 12, 2022 at 10:48 AM Lad, Prabhakar
<prabhakar.csengg@...il.com> wrote:
> On Wed, Jul 27, 2022 at 4:37 PM Rob Herring <robh@...nel.org> wrote:
> > On Tue, Jul 26, 2022 at 06:45:25PM +0100, Lad Prabhakar wrote:
> > > The CPG block on the RZ/Five SoC is almost identical to one found on the
> > > RZ/G2UL SoC. "renesas,r9a07g043-cpg" compatible string will be used on
> > > the RZ/Five SoC so to make this clear, update the comment to include
> > > RZ/Five SoC.
> >
> > It's either the same part or it isn't. 'almost identical' doesn't sound
> > like the former. Unless it's the former, it's a nak for me.
> >
> It's the latter.
To me, it looks like both blocks are identical, and the differences
are in the integration into the SoC:
1. Some clocks do not exist (are not documented?) on RZ/Five,
because the consumer blocks do not exist (are not documented?).
2. Some interrupt controller clocks and resets have different names,
but use the exact same registers and bits.
For 1, probably we could have kept those clocks anyway (they would
be disabled by CCF due to being unused). But I'm not 100% sure it is
safe to write to the corresponding registers (probably the hardware
engineers would recommend not to access the registers, regardless if
it is safe or not ;-), so we do not instantiate these clocks on RISC-V.
For 2, we decided to play it safe, too, and follow the naming in the
documentation, in both bindings and driver.
> > Litering the drivers with #ifdef CONFIG_ARM64/CONFIG_RISCV is not great
> > either. That's not great for compile coverage and they have nothing to
> > do with the architecture.
I agree #ifdef's do have disadvantages. But they seemed to be the
best pragmatic solution, to avoid two separate drivers.
And the architecture does specify SoC integration.
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