Re: [PATCH] cpufreq: Remove CPUFREQ_STICKY flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 1, 2021 at 11:06 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>
> 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 ?

It does to me, but can you update the changelog, please?



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux