[PATCH v2 5/5] test: clk: add test for CLK_LAZY_REPARENT

[Yang Xiwen]

On 1/7/2026 12:23 AM, Simon Glass wrote:
> Hi,
>
> On Wed, 31 Dec 2025 at 12:52, Yang Xiwen via B4 Relay
> <devnull+forbidden405.outlook.com at kernel.org> wrote:
>> From: Yang Xiwen <forbidden405 at outlook.com>
>>
>> Add a test for the newly introduced CLK_LAZY_PARENT feature.
>>
>> Modify clk_sandbox_ccf driver to register two clocks(i2s and i2s_root)
>> in reversed order.
>>
>> The test function then try to acquire the clocks and asserts that their
>> internal states are maintained correctly.
>>
>> Signed-off-by: Yang Xiwen <forbidden405 at outlook.com>
>> ---
>>   drivers/clk/clk_sandbox_ccf.c | 10 ++++++++++
>>   include/sandbox-clk.h         |  2 ++
>>   test/dm/clk_ccf.c             | 29 +++++++++++++++++++++++++++++
>>   3 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/clk/clk_sandbox_ccf.c b/drivers/clk/clk_sandbox_ccf.c
>> index f96a15c30b3a..3a11b361cd2b 100644
>> --- a/drivers/clk/clk_sandbox_ccf.c
>> +++ b/drivers/clk/clk_sandbox_ccf.c
>> @@ -229,6 +229,7 @@ static const struct udevice_id sandbox_clk_ccf_test_ids[] = {
>>
>>   static const char *const usdhc_sels[] = { "pll3_60m", "pll3_80m", };
>>   static const char *const i2c_sels[] = { "pll3_60m", "pll3_80m", };
>> +static const char *const i2s_sels[] = { "pll3_60m", "pll3_80m", };
>>
>>   static int sandbox_clk_ccf_probe(struct udevice *dev)
>>   {
>> @@ -277,6 +278,15 @@ static int sandbox_clk_ccf_probe(struct udevice *dev)
>>          clk_dm(SANDBOX_CLK_I2C_ROOT,
>>                 sandbox_clk_gate2("i2c_root", "i2c", base + 0x7c, 0));
>>
>> +       /* Register i2s_root(child) and i2s(parent) in reverse order to test CLK_LAZY_REPARENT */
>> +       clk_dm(SANDBOX_CLK_I2S_ROOT,
>> +              sandbox_clk_gate2("i2s_root", "i2s", base + 0x80, 0));
>> +
>> +       reg = BIT(29) | BIT(25) | BIT(17);
>> +       clk_dm(SANDBOX_CLK_I2S,
>> +              sandbox_clk_composite("i2s", i2s_sels, ARRAY_SIZE(i2s_sels),
>> +                                    &reg, CLK_SET_RATE_UNGATE));
>> +
>>          return 0;
>>   }
>>
>> diff --git a/include/sandbox-clk.h b/include/sandbox-clk.h
>> index c2616c27a44a..0cd735e3ad5f 100644
>> --- a/include/sandbox-clk.h
>> +++ b/include/sandbox-clk.h
>> @@ -21,6 +21,8 @@ enum {
>>          SANDBOX_CLK_USDHC2_SEL,
>>          SANDBOX_CLK_I2C,
>>          SANDBOX_CLK_I2C_ROOT,
>> +       SANDBOX_CLK_I2S,
>> +       SANDBOX_CLK_I2S_ROOT,
>>   };
>>
>>   enum sandbox_pllv3_type {
>> diff --git a/test/dm/clk_ccf.c b/test/dm/clk_ccf.c
>> index ac56f17b775d..c4c1b6ba758a 100644
>> --- a/test/dm/clk_ccf.c
>> +++ b/test/dm/clk_ccf.c
>> @@ -209,3 +209,32 @@ static int dm_test_clk_ccf(struct unit_test_state *uts)
>>          return 1;
>>   }
>>   DM_TEST(dm_test_clk_ccf, UTF_SCAN_FDT);
>> +
>> +#if CONFIG_IS_ENABLED(CLK_LAZY_REPARENT)
>> +/* Test CLK_LAZY_REPARENT feature */
>> +static int dm_test_clk_lazy_reparent(struct unit_test_state *uts)
>> +{
>> +       struct udevice *dev;
>> +       struct clk *clk_i2s, *clk_i2s_root;
>> +       int ret;
>> +
>> +       /* Get the device using the clk device */
>> +       ut_assertok(uclass_get_device_by_name(UCLASS_CLK, "clk-ccf", &dev));
>> +
>> +       ret = clk_get_by_id(SANDBOX_CLK_I2S_ROOT, &clk_i2s_root);
>> +       ret |= clk_get_by_id(SANDBOX_CLK_I2S, &clk_i2s);
>> +       ut_assertok(ret);
> Perhaps two separate ut_assertok() calls?


Will do in v3


>
>> +
>> +       ut_asserteq_str(clk_i2s_root->parent_name, "i2s");
>> +       ut_assertnull(clk_i2s_root->dev->parent);
>> +
>> +       ret = clk_enable(clk_i2s_root);
>> +       ut_assertok(ret);
> join those two lines up?


Will do.


>
>> +
>> +       ut_assertnull(clk_i2s_root->parent_name);
>> +       ut_asserteq_ptr(clk_i2s_root->dev->parent, clk_i2s->dev);
>> +
>> +       return 0;
>> +}
>> +DM_TEST(dm_test_clk_lazy_reparent, UTF_SCAN_FDT);
>> +#endif
>>
>> --
>> 2.43.0
>>
>>
> Could you look at tests to cover some of the other changes you made in
> this series? This is a critical subsystem so it feels strange to set a
> patch that changes existing behaviour but doesn't change any existing
> test.


That would need a lot of #ifdef s in existing tests then. This feature 
is optional.

I'm not sure but i'll have a try with as few #ifdefs as possible.


>
> Regards,
> Simon


-- 
Regards,
Yang Xiwen