[PATCH 02/11] clk: scmi: Use new determine_rate clock operation

Peng Fan peng.fan at nxp.com
Mon Mar 2 18:54:05 PST 2026


> Subject: Re: [PATCH 02/11] clk: scmi: Use new determine_rate clock
> operation
> 
> On Sat, Feb 28, 2026 at 08:56:04AM +0800, Peng Fan wrote:
> > On Fri, Feb 27, 2026 at 03:32:16PM +0000, Cristian Marussi wrote:
> > >Use the Clock protocol layer determine_rate logic to calculate the
> > >closest rate that can be supported by a specific clock.
> > >
> > >No functional change.
> > >
> > >Cc: Brian Masney <bmasney at redhat.com>
> > >Cc: Michael Turquette <mturquette at baylibre.com>
> > >Cc: Stephen Boyd <sboyd at kernel.org>
> > >Cc: linux-clk at vger.kernel.org
> > >Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> > >---
> > >Note that the calculation logic in the protocol layer is exactly the
> > >same as it wes here.
> > >
> > >@Brian I suppose once your CLK_ROUNDING_FW_MANAGED sereis
> is merged I
> > >can flag such SCMI clocks.
> >
> > Per my reading of Brain's thread, if ->determine_rate exists,
> > ->determine_rate() will be used.
> >
> >  	} else if (core->ops->determine_rate) {
> >  		return core->ops->determine_rate(core->hw, req);
> > +	} else if (clk_is_rounding_fw_managed(core)) {
> > +		return 0;
> >
> > So unless update scmi_clk_determine_rate() to something:
> > --------
> > if (clk & CLK_ROUNDING_FW_MANAGED)
> > 	return 0;
> >
> > return scmi_proto_clk_ops->determine_rate(clk->ph, clk->id,
> > &req->rate);
> > --------
> >
> > It maybe better to update Brain's patch to move
> > clk_is_rounding_fw_managed() above the check of core->ops-
> >determine_rate().
> 
> The clk framework has some basic sanity checks in place that are called
> during device probe to ensure that various ops are configured properly.
> I could add a check that if CLK_ROUNDING_FW_MANAGED [*] is set,
> and a
> determine_rate() op is set, then it gives an error.

Sounds good to me.

Thanks
Peng.

> 
> [*] Note: I am tentatively planning to rename that to
> CLK_ROUNDING_NOOP in v2 in about a week.
> 
> Brian
> 




More information about the linux-arm-kernel mailing list