[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+V-a8sj-jEu8y_qPv-KvVCu_YQCQ1MDK9zrRB93LjfhmB_qfQ@mail.gmail.com>
Date: Wed, 5 Mar 2025 16:37:40 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>,
Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 1/3] clk: renesas: rzv2h-cpg: Move PLL access macros to
source file
Hi Geert,
Thank you for the review.
On Wed, Mar 5, 2025 at 4:19 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, 18 Feb 2025 at 12:44, Prabhakar <prabhakar.csengg@...il.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Move the `PLL_CLK_ACCESS()`, `PLL_CLK1_OFFSET()`, and `PLL_CLK2_OFFSET()`
> > macros from `rzv2h-cpg.h` to `rzv2h-cpg.c`, as they are not intended for
> > use by SoC-specific CPG drivers.
> >
> > Additionally, update `PLL_CLK1_OFFSET()` and `PLL_CLK2_OFFSET()` to use
> > the `FIELD_GET()` macro for better readability and simplify the
> > `PLL_CLK_ACCESS()` macro.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>
> Thanks for your patch!
>
> The changes look correct to me, so
> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> but I still have some comments...
>
> > --- a/drivers/clk/renesas/rzv2h-cpg.c
> > +++ b/drivers/clk/renesas/rzv2h-cpg.c
> > @@ -56,6 +56,10 @@
> >
> > #define CPG_CLKSTATUS0 (0x700)
> >
> > +#define PLL_CLK_ACCESS(n) (!!((n) & BIT(31)))
>
> OK
>
> > +#define PLL_CLK1_OFFSET(n) FIELD_GET(GENMASK(15, 0), (n))
> > +#define PLL_CLK2_OFFSET(n) (PLL_CLK1_OFFSET(n) + (0x4))
>
> IMO, the original versions are more readable, as they clearly show
> the symmetry between encoding and decoding.
>
> Perhaps a good alternative would be a structure with bitfields and
> a PACK() macro, like is used for DDIV and SMUX?
>
Sure, I'll do that. Is it OK if I make that change on top of this
series or do you want me to rework and send a v2?
Cheers,
Prabhakar
Powered by blists - more mailing lists