Re: [PATCH 1/3] clk: socfpga: agilex: convert to CLK_OF_DECLARE()

[Dinh Nguyen <dinguyen@kernel.org>]

Hi Brian,

On 9/21/26 09:52, Brian Masney wrote:
> + Bartosz
> 
> Hi Adrian,
> 
> On Mon, Sep 21, 2026 at 11:17:13AM +0800, Ng, Adrian Ho Yin wrote:
>> subsys_initcall() / subsys_platform_driver() would not fix the failure we
>> are hitting. Both still run after time_init(), while the DW APB timer is
>> registered via TIMER_OF_DECLARE from timer_probe().
>>
>> So moving from core_initcall() to subsys_initcall() changes nothing for
>> this consumer: the timer cannot defer, clk_get() still fails, and the timer
>> is never brought up. That is why these patches use CLK_OF_DECLARE(): the
>> provider must be registered from of_clk_init() so clocks exist before
>> TIMER_OF_DECLARE runs.
>>
>> On the broader point about CLK_OF_DECLARE abuse: I agree it should not be
>> used merely to beat platform device probe. If the preferred approach is to
>> keep the clkmgr as a platform driver (subsys_platform_driver()) and give the
>> DW APB timer nodes a fixed clock-frequency instead of a clocks phandle, I
>> can respin that way. Please let me know which you prefer.
> 
> I wanted confirmation that you wanted to use CLK_OF_DECLARE() for the
> system timers.
> 
> Will you by chance be at Linux Plumbers Conference in two weeks? Bartosz
> is leading a discussion about the future of CLK_OF_DECLARE() and
> friends.
> 
> https://lpc.events/event/20/contributions/2503/
> 
> We want to minimize the use of CLK_OF_DECLARE(), so the preference is
> to keep this as a platform driver if possible. If you are able to get
> around using CLK_OF_DECLARE() by initially running the system timers
> with a fixed frequency then I think that would be preferable.

I originally pushed back on hard-coding a fixed frequency for these 
timers because if the bootloader changed the frequency of the clocks for 
these timers, we may run in to a problem. But I don't think the 
bootloader had changed the clock frequency in a long time, so it may not 
really be a problem. But it just feels wrong to not take in a frequency 
from the clock driver.

The other option is perhaps adding the ability to defer probe these timers?

Thanks,
Dinh