Re: [00/36] clk: port Linux Common Clock Framework to U-Boot

Hi Casey,

On 2026-07-20T16:40:27, Casey Connolly <[email protected]> wrote:

> Casey Connolly (36):
>        ...
>        clk/qcom/ccf: adapt sm8650 clock drivers for U-Boot
>        ufs: qcom: use clk_prepare_enable_bulk()
>        qcom_sm8650_defconfig: enable CCF_FULL
>        ufs: qcom: fix core clk max rate setting

I have had a look through the patches and the concept looks good to
me. But first want to mention a fairly major point:

Please can you reconsider UCLASS_NOP for the clock providers?

Every provider node gets its own device, so this isn't one device for
the tree - on SM8650 it is gcc, dispcc, tcsrcc and rpmh today, plus
every fixed-clock and fixed-factor-clock node, and more clock
controllers as they are ported. They all show up in 'dm tree' as nop.
Ick.

A dedicated uclass (UCLASS_CLK_CCF, say) would give you somewhere to
hang of_clk_add_provider() and the orphan reparenting from post_probe,
so drivers can't forget to do it, along with a home for per-provider
uclass_plat and something meaningful in 'dm tree'.

Where it really pays off is lookup. In patch 11,
of_clk_get_hw_from_clkspec() calls device_get_global_by_ofnode() and
then walks of_clk_providers comparing the same ofnode, so it does two
lookups keyed on the same thing, one of which driver model already
does for you. With the providers in a uclass that becomes a single
uclass_find_device_by_ofnode() and of_clk_providers (and its mutex)
can go. That only works once every provider is in the uclass, though,
which brings me to the next point.

I appreciate the point of UCLASS_NOP is that a PHY or PMIC can provide
clocks without a second driver...fair enough. You may have seen my
series adding uclass adjuncts[1], which lets a device join extra
uclasses without child devices, so a PHY would keep UCLASS_PHY and add
a clock adjunct. That would also let gcc and dispcc drop the reset and
power domain child devices from qcom_cc_bind_pd_reset() entirely.

I'm not sure if that series will ever go in and I'm not asking you to
depend on it - but the uclass change stands on its own and heads in
that direction. In the meantime nothing is lost: a PHY or PMIC can
keep registering its clocks from its own probe exactly as it does now,
it just doesn't need the post_probe hook and the ofnode lookup stays
as it is.

BTW we should not assume that Linux support comes before U-Boot...in
general you need U-Boot running so your can boot Linux! But that is
really just another argument in favour of this series - yes, you must
put in more effort on the U-Boot clock driver, but then you will be
able to use the same code in Linux.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=496717&state=*