* [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization
@ 2021-10-19 15:28 Lingutla Chandrasekhar
2021-10-19 17:05 ` Lukasz Luba
0 siblings, 1 reply; 4+ messages in thread
From: Lingutla Chandrasekhar @ 2021-10-19 15:28 UTC (permalink / raw)
To: lukasz.luba, rafael.j.wysocki, qperret, daniel.lezcano
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, Lingutla Chandrasekhar
em_dev_register_perf_domain() can be called from any initcall level before
debugfs initialization, this allowed to create power domain debug entries
of the caller at unintended root_dir.
Fix it by not allowing creation of power domain debug entries, if root_dir
is not available.
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index a332ccd829e2..fe5a207d4023 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -68,6 +68,11 @@ static void em_debug_create_pd(struct device *dev)
struct dentry *d;
int i;
+ if (!rootdir) {
+ pr_err("EM: energy_model debug is not available yet\n");
+ return;
+ }
+
/* Create the directory of the performance domain */
d = debugfs_create_dir(dev_name(dev), rootdir);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization
2021-10-19 15:28 [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization Lingutla Chandrasekhar
@ 2021-10-19 17:05 ` Lukasz Luba
2021-10-20 12:03 ` Chandrasekhar L
0 siblings, 1 reply; 4+ messages in thread
From: Lukasz Luba @ 2021-10-19 17:05 UTC (permalink / raw)
To: Lingutla Chandrasekhar
Cc: rafael.j.wysocki, qperret, daniel.lezcano, linux-arm-kernel,
linux-kernel, linux-arm-msm
On 10/19/21 4:28 PM, Lingutla Chandrasekhar wrote:
> em_dev_register_perf_domain() can be called from any initcall level before
The EM is registered by cpufreq drivers (or devfreq), which is later
than fs_initcall, so the debugfs is setup. We even have added recently
a dedicated callback into the cpufreq (register_em()) for that.
Do you have such code which registers EM for CPUs (or some devfreq)
earlier than this fs_initcall?
I cannot find such code in mainline.
Regards,
Lukasz
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization
2021-10-19 17:05 ` Lukasz Luba
@ 2021-10-20 12:03 ` Chandrasekhar L
2021-10-20 12:54 ` Lukasz Luba
0 siblings, 1 reply; 4+ messages in thread
From: Chandrasekhar L @ 2021-10-20 12:03 UTC (permalink / raw)
To: Lukasz Luba
Cc: rafael.j.wysocki, qperret, daniel.lezcano, linux-arm-kernel,
linux-kernel, linux-arm-msm
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?
One of such example is, 'drivers/cpufreq/qcom-cpufreq-hw.c' uses postcore_initcall().
Thanks,
Chandrasekhar L
On 10/19/2021 10:35 PM, Lukasz Luba wrote:
>
>
> On 10/19/21 4:28 PM, Lingutla Chandrasekhar wrote:
>> em_dev_register_perf_domain() can be called from any initcall level before
>
> The EM is registered by cpufreq drivers (or devfreq), which is later
> than fs_initcall, so the debugfs is setup. We even have added recently
> a dedicated callback into the cpufreq (register_em()) for that.
>
> Do you have such code which registers EM for CPUs (or some devfreq)
> earlier than this fs_initcall?
>
> I cannot find such code in mainline.
>
> Regards,
> Lukasz
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization
2021-10-20 12:03 ` Chandrasekhar L
@ 2021-10-20 12:54 ` Lukasz Luba
0 siblings, 0 replies; 4+ messages in thread
From: Lukasz Luba @ 2021-10-20 12:54 UTC (permalink / raw)
To: Chandrasekhar L
Cc: rafael.j.wysocki, qperret, daniel.lezcano, linux-arm-kernel,
linux-kernel, linux-arm-msm
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-10-20 12:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-19 15:28 [PATCH] PM: EM: do not allow pd creation prior to debugfs initialization Lingutla Chandrasekhar
2021-10-19 17:05 ` Lukasz Luba
2021-10-20 12:03 ` Chandrasekhar L
2021-10-20 12:54 ` Lukasz Luba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).