[PATCH RFC 00/40] clk: port full Linux Common Clock Framework to U-Boot

[Casey Connolly]

Hi Neil,

On 20/03/2026 18:55, Neil Armstrong wrote:

[...]

>>>
>>> === clk_ops/UCLASS_CLK ===
>>>
>>> CCF_FULL drivers should NOT use UCLASS_CLK, since CCF uses a totally
>>> independent clock API. If the clocks are provided by another device like
>>> a phy, they can simply be registered with the clk core the same way they
>>> are in Linux. Standalone clock drivers should use UCLASS_NOP.
>>
>> Bypassing UCLASS_CLK entirely is a big departure. It means DM can't
>> track these clock devices properly - no uclass_find_device(), no
>> sequence numbers, no standard device iteration.
>>
> 
> Can't we allocate struct clk as udevices subdevices of clk drivers ?
> 
> Like alloc_clk() woult create a child udevice of dev and the lookup
> functions would use the uclass functions and use dm for all the
> allocation and lifetime of the clk.
> 
> This is what I did for the interconnect, and it works well. You
> can easily create/attach/find/iterate/remove subdevices instead
> of using custom alloc and lists.

This is what the existing U-Boot CCF does, while we totally could go
with this approach it would involve a lot of changes to CCF to use DM to
manage the clock tree but I don't think we'd gain much.... We'd
basically just end up with the CCF U-Boot already has where every
clk_ops needs it's own driver definition and we have to rely much more
on string based lookups.

If I were writing my own CCF for U-Boot from scratch I could imagine
going this way, clearly it has some value for the existing
implementation... But yeah the allocation and lifetime management is
already just there and battle tested as well as doing some thing DM
alone can't like keeping around but stubbing a clk_core if the provider
is removed without breaking consumers.

> 
> Neil
> 


-- 
// Casey (she/her)