Re: [PATCH] clk: add new Kconfig to control default behavior of disabling unused clocks

Jagadeesh Kona
2026-03-19T05:40:51Z

On 3/17/2026 7:50 PM, Abel Vesa wrote:
> On 26-03-17 10:13:08, Brian Masney wrote:
>> On Tue, Mar 17, 2026 at 03:21:17PM +0200, Abel Vesa wrote:
>>> The solution has been already discussed for a long time now and it is:
>>> drop the clk_ignore_unused late_initcall entirely and then make a
>>> generic sync_state callback that the clock providers can use (or they
>>> could implement one themselves). This way, until sync_state is reached
>>> for a specific clock provider driver, all unused clocks remain as is.
>>
>> I'm willing to work on the sync state support once my clk scaling
>> series [1] lands upstream. I believe that Saravana posted a series
>> related to clk sync state, and I need to look at that.
>
> Yeah, I've spent time on it a couple of years as well, but got side
> tracked...
>
> I'd be nice if this actually lands soon.
>

Yeah, In Qualcomm SoCs, we have use cases where certain consumer drivers are
probed after the late init call. These drivers rely on clocks that are already
enabled by the bootloader and expect those clocks to remain ON until their probe
completes, after which these consumer drivers can vote on the required clocks.
Supporting sync_state for clocks appears to be the right mechanism to address
this requirement.

Thanks,
Jagadeesh

>>
>> FWIW, the only reason I posted this patch is because at the end of
>> Stephen's LPC talk I got the impression that this was also an acceptable
>> change. I'm fine with dropping this change.
>
> Here is the scenario that proves adding such config isn't the right
> solution: think of single kernel image working with different SoCs from
> different vendors. This is actually the case where distros need to have
> a way to provide one kernel image + thousands of DTBs and be able to
> boot one each one of the boards. Whatever this config is set to in the
> kernel image, it will not work with all platforms.
>