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

[Marek Vasut]

On 11/17/25 5:36 PM, Patrice CHOTARD wrote:

Hello Patrice,

> 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.

I don't think any clock driver can depend on SCMI clock shortnames for 
clock look up, because the SCMI clock shortnames are an optional hint.

Instead, if some clock registered in this RCC driver have SCMI parent 
clock, those SCMI parent clock have to be referred to by SCMI clock 
udevice and matching clock identifier (in this case, I assume that would 
be SCMI clock ID).

The relationship between this RCC clock and SCMI parent clock can likely 
be described in DT using 'clocks = <&scmi_clk N>' , which you already 
have in stm32mp131.dtsi:

  788                         clock-names = "hse", "hsi", "csi", "lse", 
"lsi";
  789                         clocks = <&scmi_clk CK_SCMI_HSE>,
  790                                  <&scmi_clk CK_SCMI_HSI>,
  791                                  <&scmi_clk CK_SCMI_CSI>,
  792                                  <&scmi_clk CK_SCMI_LSE>,
  793                                  <&scmi_clk CK_SCMI_LSI>;

Can you use that for the parent lookup and simply ignore the shortnames?