[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdURtL1u-MDXBhiwOfX+zBnuunZYvjt+3GMOp6Y6pj1Efw@mail.gmail.com>
Date: Thu, 14 Mar 2024 15:48:45 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Samuel Holland <samuel.holland@...ive.com>
Cc: Albert Ou <aou@...s.berkeley.edu>, linux-clk@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
Emil Renner Berthing <kernel@...il.dk>, Hal Feng <hal.feng@...rfivetech.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Conor Dooley <conor.dooley@...rochip.com>,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH] clk: starfive: jh7100: Use provided clocks instead of
hardcoded names
Hi Samuel,
On Thu, Mar 14, 2024 at 3:32 PM Samuel Holland
<samuel.holland@...ive.com> wrote:
> On 2024-03-14 6:05 AM, Geert Uytterhoeven wrote:
> > The Starfive JH7100 clock driver does not use the DT "clocks" property
> > to find its external input clocks, but instead relies on the names of
> > the actual external clock providers. This is fragile, and caused
> > breakage when sanitizing clock names in DT.
> >
> > Fix this by obtaining the external input clocks through the DT "clocks"
> > property, and using their clk_hw objects or corresponding name.
> >
> > Fixes: f03606470886 ("riscv: dts: starfive: replace underscores in node names")
> > Fixes: 4210be668a09ee20 ("clk: starfive: Add JH7100 clock generator driver")
> > Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> > --- a/drivers/clk/starfive/clk-starfive-jh7100.c
> > +++ b/drivers/clk/starfive/clk-starfive-jh7100.c
> > @@ -298,13 +311,23 @@ static int __init clk_starfive_jh7100_probe(struct platform_device *pdev)
> > if (IS_ERR(priv->base))
> > return PTR_ERR(priv->base);
> >
> > + for (idx = 0; idx < EXT_NUM_CLKS; idx++) {
> > + clk = devm_clk_get(&pdev->dev, jh7100_ext_clk[idx]);
> > + if (IS_ERR(clk))
> > + return PTR_ERR(clk);
> > +
> > + priv->ext[idx] = __clk_get_hw(clk);
> > + }
> > +
> > + osc_sys = clk_hw_get_name(priv->ext[EXT_CLK_OSC_SYS]);
> > +
> > priv->pll[0] = devm_clk_hw_register_fixed_factor(priv->dev, "pll0_out",
> > - "osc_sys", 0, 40, 1);
> > + osc_sys, 0, 40, 1);
> > if (IS_ERR(priv->pll[0]))
> > return PTR_ERR(priv->pll[0]);
> >
> > priv->pll[1] = devm_clk_hw_register_fixed_factor(priv->dev, "pll1_out",
> > - "osc_sys", 0, 64, 1);
> > + osc_sys, 0, 64, 1);
>
> These should use devm_clk_hw_register_fixed_factor_parent_hw(). (Or you could
Thanks, I didn't know about that function!
> define a devm_clk_hw_register_fixed_factor_fw_name() and drop the other changes.)
Sorry, I don't understand what you mean here?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg
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