On 01-02-21, 10:44, Dominik Brodowski wrote: > IIRC, it was required on various ARM systems,[*] as CPUs were registered as > subsys_initcall(), while cpufreq used to be initialized only later, as an s/later/earlier ? arch happens before subsys not at least and that is the only way we can break cpufreq here, i.e. when the driver comes up before the CPUs are registered. > arch_initcall(). If the ordering is opposite now on all architectures (it > wasn't on ARM back then), we should be fine. > > [*] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/arm/mach-sa1100/cpu-sa1100.c?id=f59d3bbe35f6268d729f51be82af8325d62f20f5 Thanks for your reply, it made me look at that aspect in some more detail to confirm I don't end up breaking anything. Unless I am making a mistake in reading the code, this is the code flow that we have right now: start_kernel() -> kernel_init() -> kernel_init_freeable() -> do_basic_setup() -> driver_init() -> cpu_dev_init() -> subsys_system_register(for-CPUs) -> do_initcalls() -> register-cpufreq-driver from any level And so CPUs should always be there for a cpufreq driver. Makes sense ? -- viresh
