Re: [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization
From: Lukasz Luba <lukasz.luba@arm.com>
Date: 2021-10-20 12:54:10
Also in:
linux-arm-msm, lkml
On 10/20/21 1:03 PM, Chandrasekhar L wrote:
Thanks Lukasz for comment. For any reason (ex: HW dependency, etc), if init_call level of cpufreq/devfreq driver changed prior to fs_init call, we would land there right?
It's not the same triggering point, so we should be safe.
One of such example is, 'drivers/cpufreq/qcom-cpufreq-hw.c' uses postcore_initcall().
It uses the postcore_initcall to probe and register a driver into the cpufreq framework. Then the cpufreq framework later constructs the 'policy' and calls your cpufreq_driver::init() function that your driver provided during registration. Thus, these are two different phases. It used to be true that if a driver required to use an 'advanced' EM registration with custom private 'em_data_callback', we put the registration call into that .init() code [1] (old [2]). Recently Viresh added a dedicated callback for this, which IMO is good and avoids confusion where to put that custom registration code. In your driver code, there is also this callback but using a generic function [3]. It's a 'simple' EM, which is based on OPP framework helper. A few drivers use that option, if their platform doesn't need the 'advanced' EM (but that's not in $subject). Regards, Lukasz [1] https://elixir.bootlin.com/linux/v5.15-rc1/source/drivers/cpufreq/scmi-cpufreq.c#L249 [2] https://elixir.bootlin.com/linux/v5.14/source/drivers/cpufreq/scmi-cpufreq.c#L192 [3] https://elixir.bootlin.com/linux/v5.15-rc6/source/drivers/cpufreq/qcom-cpufreq-hw.c#L561 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel