On 11/14/25 4:41 PM, Patrice Chotard wrote:
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 ?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")
This kind of a workaround with Kconfig symbol is not the right solution.
