Messages in this thread | | | Date | Tue, 17 Sep 2019 10:34:12 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH 5/5] cpufreq: qcom-hw: Move driver initialisation earlier |
| |
On Thu, Sep 12, 2019 at 04:02:34AM +0530, Amit Kucheria wrote: > Allow qcom-hw driver to initialise right after the cpufreq and thermal > subsystems are initialised in core_initcall so we get earlier access to > thermal mitigation. > > Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> > --- > drivers/cpufreq/qcom-cpufreq-hw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c > index 4b0b50403901..04676cc82ba6 100644 > --- a/drivers/cpufreq/qcom-cpufreq-hw.c > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c > @@ -327,7 +327,7 @@ static int __init qcom_cpufreq_hw_init(void) > { > return platform_driver_register(&qcom_cpufreq_hw_driver); > } > -device_initcall(qcom_cpufreq_hw_init); > +postcore_initcall(qcom_cpufreq_hw_init);
I am fine with core framework initcall pushed to earlier initcall levels if required, but for individual/platform specific drivers I am not so happy to see that.
This goes against the grand plan of single common kernel strategy by Android moving all drivers as modules. We might decide to make this a module. Also there are few cpufreq drivers that are modules. Will they have issues ? If not, why do we need this change at all. Needing thermal mitigation during boot this earlier is still too much of expectation, I would rather boot slowly than relying on this feature.
-- Regards, Sudeep
| |