[PATCH 2/6] clk: scmi: Force call of scmi_clk_get_attribute() during probe

[Patrice CHOTARD]

On 11/15/25 00:08, Marek Vasut wrote:
> On 11/14/25 4:41 PM, Patrice Chotard wrote:
>> Since commit fdb1bffe2827 ("clk: scmi: Postpone clock name resolution"),
>> all clocks which are parent clocks are name "scmi-%zu" which
>> leads to error during their children clocks registration.
>>
>> In order to not cancel boot time optimization done in
>> commit 3547e315c188 ("clk: scmi: Defer issue of SCMI_CLOCK_ATTRIBUTES"),
>> choice has been done to re-introduce scmi_clk_get_attribute() call
>> during scmi_clk_probe() under new CLK_SCMI_FORCE_ATTRIBUTE flag.
>>
>> This restores boot on stm32mp13 and stm32mp2 family boards.
>>
>> Fixes: fdb1bffe2827 ("clk: scmi: Postpone clock name resolution")
> SCMI spec says that clock IDs have to be monotonic and incrementing, without gaps . This driver registers all SCMI clock for you exactly this way. What exactly is the problem on STM32 ? Are you maybe missing some reparenting somewhere else ? Maybe the clock parent resolution should happen when the clock are first used, just like attributes are now resolved when the clock are first used ?

Hi Marek

Initially, on STM32 we first registered SCMI clocks with their real names and then we registered all RCC clocks 
in stm32_rcc_init(). For most of these latter clocks, their parent are SCMI clocks.

After commit fdb1bffe2827 ("clk: scmi: Postpone clock name resolution"), the name of these SCMI "parent" clocks
becames "scmi-%zu" which makes clk_register() failed as we still try to register RCC clocks using their parent's "real names".

For example: for STM32MP13, clock "ck_hse" becames "scmi-0", so all clocks which are "ck_hse"'s child can't be registered.

Patrice> 
> This kind of a workaround with Kconfig symbol is not the right solution.