Currently, the U-Boot clk framework mandates that clock registration begins at the root and proceeds to children. This creates an additional requirement that does not exist in the Linux kernel, making the porting of clk drivers more difficult.
This series handles the dependency entirely within the clk framework, allowing drivers the freedom to register clocks in any order. This is achieved by assigning the parent "lazily". The framework caches the parent name in the core clk struct and attempts to resolve the actual parent when clk consumers call clk_get_parent(). The process is transparent to clk consumers as long as they use standard clk framework APIs. I've run `ut dm clk*` and verified these commits do not break any existing test cases. It also passes the new test case. This feature is disabled for xPLs by default. I have not found a clean way to enable this separately for xPLs without introducing a repetitive Kconfig entry (e.g., xPL_CLK_LAZY_REPARENT), which looks very ugly. Signed-off-by: Yang Xiwen <[email protected]> --- Changes in v2: - tests: add a simple test for this feature - clk: restrict this feature to only U-Boot proper, excluding xPLs from support (Tom) - clk: some minor tweaks that should not matter too much - Link to v1: https://lore.kernel.org/r/[email protected] --- Yang Xiwen (5): drivers: core: device: set new parent when old parent is NULL clk: add uclass id check to clk_get_parent() clk: use clk_get_parent() helper in clk_en(dis)able() clk: allow assigning parent lazily test: clk: add test for CLK_LAZY_REPARENT drivers/clk/Kconfig | 12 ++++++++ drivers/clk/clk-uclass.c | 72 +++++++++++++++++++++++++++++++++++-------- drivers/clk/clk.c | 14 +++++++-- drivers/clk/clk_sandbox_ccf.c | 10 ++++++ drivers/core/device.c | 5 +++ include/clk.h | 2 ++ include/sandbox-clk.h | 2 ++ test/dm/clk_ccf.c | 29 +++++++++++++++++ 8 files changed, 132 insertions(+), 14 deletions(-) --- base-commit: 721eecd9cbf2cc59c5230abd37d02d4a02f75cc7 change-id: 20250621-clk-reparent-89d75f6a8e09 Best regards, -- Yang Xiwen <[email protected]>
