[PATCH RFC 0/3] clk: support arbitrary clk_register() sequence

[Tom Rini]

On Tue, Oct 28, 2025 at 11:49:43PM +0800, Yang Xiwen wrote:
> On 10/15/2025 6:03 AM, Tom Rini wrote:
> > On Sat, Jun 21, 2025 at 06:54:17PM +0800, Yang Xiwen wrote:
> > 
> > > Currently U-Boot clk framework mandates the sequence of registering clks
> > > to begin from root, and then its children. This is an addtional
> > > requirement that doesn't exist in Linux kernel, which makes clk driver
> > > porting more difficult.
> > > 
> > > Let's handle this entirely in clk framework and give driver the freedom
> > > to register clocks in any order.
> > > 
> > > This is done by assigning the parent "lazily". It will cache the parent
> > > name in the core clk struct and try to refresh it when clk consumers
> > > call clk_get_parent(). It's transparent to clk consumers as long as they
> > > only use APIs provided by clk framework.
> > > 
> > > I've ran `ut dm clk*` and verified these commits does not break any
> > > existing testcases. Though no new testcase is added because I think
> > > existing testcases already test the logic very well.
> > Sorry for the very late review. When I build this on say
> > rock-4c-plus-rk3399 this is the size growth I see:
> >              rock-4c-plus-rk3399: all +228 spl/u-boot-spl:all +500 spl/u-boot-spl:text +500 text +228 tpl/u-boot-tpl:all +552 tpl/u-boot-tpl:text +552
> >                 u-boot: add: 1/0, grow: 1/0 bytes: 228/0 (228)
> >                   function                                   old     new   delta
> >                   device_reparent                              -     120    +120
> >                   clk_get_parent                              56     164    +108
> >                 spl-u-boot-spl: add: 4/0, grow: 1/0 bytes: 500/0 (500)
> >                   function                                   old     new   delta
> >                   uclass_find_device_by_namelen                -     172    +172
> >                   device_reparent                              -     120    +120
> >                   clk_get_parent                              56     144     +88
> >                   uclass_find_device_by_name                   -      68     +68
> >                   uclass_get_device_by_name                    -      52     +52
> >                 tpl-u-boot-tpl: add: 5/0, grow: 1/0 bytes: 552/0 (552)
> >                   function                                   old     new   delta
> >                   uclass_find_device_by_namelen                -     172    +172
> >                   device_reparent                              -     120    +120
> >                   clk_get_parent                              56     144     +88
> >                   uclass_find_device_by_name                   -      68     +68
> >                   uclass_get_device_by_name                    -      52     +52
> >                   strncmp                                      -      52     +52
> > 
> > (using buildman's 'bloat' features to report size change). I'm fine with
> > the growth in U-Boot itself, but that's just too much in SPL and TPL and
> > we need to figure out if we can avoid that somehow.
> > 
> I'll make this feature optional for  SPL/TPL, but would still like it to be
> always enabled for U-Boot itself.

Sounds reasonable, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251028/1dd36eb6/attachment.sig>