Re: [PATCH v2 1/3] clk: renesas: r9a09g047: Add clock and reset signals for the GBETH IPs

[Geert Uytterhoeven]

Hi John,

On Wed, 18 Jun 2025 at 12:04, John Madieu <john.madieu.xa@xxxxxxxxxxxxxx> wrote:
> > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> > On Wed, 11 Jun 2025 at 11:02, John Madieu <john.madieu.xa@xxxxxxxxxxxxxx>
> > wrote:
> > > Add clock and reset entries for the Gigabit Ethernet Interfaces (GBETH
> > > 0-1) IPs found on the RZ/G3E SoC. This includes various PLLs,
> > > dividers, and mux clocks needed by these two GBETH IPs.
> > >
> > > Reviewed-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > Tested-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > Signed-off-by: John Madieu <john.madieu.xa@xxxxxxxxxxxxxx>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/clk/renesas/r9a09g047-cpg.c
> > > +++ b/drivers/clk/renesas/r9a09g047-cpg.c

> > > @@ -214,6 +252,30 @@ static const struct rzv2h_mod_clk
> > r9a09g047_mod_clks[] __initconst = {
> > >                                                 BUS_MSTOP(8, BIT(4))),
> > >         DEF_MOD("sdhi_2_aclk",                  CLK_PLLDTY_ACPU_DIV4,
> > 10, 14, 5, 14,
> > >                                                 BUS_MSTOP(8, BIT(4))),
> > > +       DEF_MOD("gbeth_0_clk_tx_i",             CLK_SMUX2_GBE0_TXCLK,
> > 11, 8, 5, 24,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_0_clk_rx_i",             CLK_SMUX2_GBE0_RXCLK,
> > 11, 9, 5, 25,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_0_clk_tx_180_i",         CLK_SMUX2_GBE0_TXCLK,
> > 11, 10, 5, 26,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_0_clk_rx_180_i",         CLK_SMUX2_GBE0_RXCLK,
> > 11, 11, 5, 27,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_0_aclk_csr_i",           CLK_PLLDTY_DIV8, 11, 12,
> > 5, 28,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_0_aclk_i",               CLK_PLLDTY_DIV8, 11, 13,
> > 5, 29,
> > > +                                               BUS_MSTOP(8, BIT(5))),
> > > +       DEF_MOD("gbeth_1_clk_tx_i",             CLK_SMUX2_GBE1_TXCLK,
> > 11, 14, 5, 30,
> > > +                                               BUS_MSTOP(8, BIT(6))),
> > > +       DEF_MOD("gbeth_1_clk_rx_i",             CLK_SMUX2_GBE1_RXCLK,
> > 11, 15, 5, 31,
> > > +                                               BUS_MSTOP(8, BIT(6))),
> > > +       DEF_MOD("gbeth_1_clk_tx_180_i",         CLK_SMUX2_GBE1_TXCLK,
> > 12, 0, 6, 0,
> >
> > scripts/checkpatch.pl says:
> >
> >     WARNING: please, no space before tabs
> >
>
> Noted.
>
> > > +                                               BUS_MSTOP(8, BIT(6))),
> > > +       DEF_MOD("gbeth_1_clk_rx_180_i",         CLK_SMUX2_GBE1_RXCLK,
> > 12, 1, 6, 1,
> > > +                                               BUS_MSTOP(8, BIT(6))),
> > > +       DEF_MOD("gbeth_1_aclk_csr_i",           CLK_PLLDTY_DIV8, 12, 2,
> > 6, 2,
> > > +                                               BUS_MSTOP(8, BIT(6))),
> > > +       DEF_MOD("gbeth_1_aclk_i",               CLK_PLLDTY_DIV8, 12, 3,
> > 6, 3,
> > > +                                               BUS_MSTOP(8, BIT(6))),
> >
> > Shouldn't all of these use DEF_MOD_MUX_EXTERNAL() instead of DEF_MOD(),
> > like on RZ/V2H and RZ/V2N?
> >
>
> Do we really need to use DEF_MOD_MUX_EXTERNAL? Unlike for the RZ/V2H,
> On G3E, unbind/bind works with DEF_MOD. I can however switch to
> DEF_MOD_MUX_EXTERNAL for consistency if required.
>
> Please let me know.

Does that mean the monitor bits on RZ/G3E do reflect the correct state of
external clocks? If yes, then DEF_MOD() is fine.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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