linux-kernel - Re: [RFC PATCH v2 4/4] clk: renesas: Add RZ/V2H(P) CPG driver

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] [day] [month] [year] [list]

Date: Thu, 27 Jun 2024 14:27:34 +0100
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>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Magnus Damm <magnus.damm@...il.com>, linux-renesas-soc@...r.kernel.org, 
	linux-clk@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [RFC PATCH v2 4/4] clk: renesas: Add RZ/V2H(P) CPG driver

Hi Geert,

Thank you for the review.

On Wed, Jun 26, 2024 at 11:14 AM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
> On Tue, Jun 11, 2024 at 1:32 AM Prabhakar <prabhakar.csengg@...il.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Add RZ/V2H(P) CPG driver.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > ---
> > v1->v2
> > - Updated commit description
> > - Dropped pll_clk1/clk2_offset
> > - Made r9a09g057_mod_clks/r9a09g057_resets as static const
> > - Now using register indexes
>
> Thanks for the update!
>
> > --- /dev/null
> > +++ b/drivers/clk/renesas/r9a09g057-cpg.c
>
> > +static const struct rzv2h_mod_clk r9a09g057_mod_clks[] = {
> > +       DEF_MOD("scif_0_clk_pck", CLK_PLLCM33_DIV16, 8, 15, 4, 15),
>
> So this relates to module clock 8 * 16 + 15 = 143 in DTS...
>
Yep.

> > +};
> > +
> > +static const struct rzv2h_reset r9a09g057_resets[] = {
> > +       DEF_RST(9, 5, 4, 6),            /* SCIF_0_RST_SYSTEM_N */
> > +};
> > +
> > +static const unsigned int r9a09g057_crit_mod_clks[] __initconst = {
> > +       MOD_CLK_BASE + 5,               /* ICU_0_PCLK_I */
> > +       MOD_CLK_BASE + 19,              /* GIC_0_GICCLK */
>
> So these relate to module clocks 5 and 19 in DTS.
>
> Actually none of these clocks are created in the driver yet, so I think
> these critical clocks belong to the patch that will introduce them.
>
> I am wondering if critical clocks should just use a flag in DEF_MOD()
> instead...
>
Agreed, I will add a flag for it and have two macros like below,

#define DEF_MOD_BASE(_name, _parent, _id, _critical, _onindex, _onbit,
_monindex, _monbit) \
    { \
        .name = (_name), \
        .parent = (_parent), \
        .id = (_id), \
        .critical = (_critical), \
        .on_index = (_onindex), \
        .on_bit = (_onbit), \
        .mon_index = (_monindex), \
        .mon_bit = (_monbit), \
    }

#define MOD_CLK_ID(x)    (MOD_CLK_BASE + (x))
#define MOD_ID(x, y)    ((((x) * 16)) + (y))

#define DEF_MOD(_name, _parent, _onindex, _onbit, _monindex, _monbit)        \
    DEF_MOD_BASE(_name, _parent, MOD_CLK_ID(MOD_ID(_onindex, _onbit)),    \
             false, _onindex, _onbit, _monindex, _monbit)

#define DEF_MOD_CRITICAL(_name, _parent, _onindex, _onbit, _monindex,
_monbit)    \
    DEF_MOD_BASE(_name, _parent, MOD_CLK_ID(MOD_ID(_onindex, _onbit)),    \
             true, _onindex, _onbit, _monindex, _monbit)


Cheers,
Prabhakar