Messages in this thread | | | Date | Tue, 6 Oct 2020 18:09:16 +0100 | From | Ionela Voinescu <> | Subject | Re: [PATCH 1/2] cpufreq,arm,arm64: restructure definitions of arch_set_freq_scale() |
| |
Hi Viresh,
On Tuesday 06 Oct 2020 at 12:35:51 (+0530), Viresh Kumar wrote: > On 24-09-20, 13:30, Ionela Voinescu wrote: > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > index 2ea245a6c0c0..f34d3a3d5ba6 100644 > > --- a/drivers/cpufreq/cpufreq.c > > +++ b/drivers/cpufreq/cpufreq.c > > @@ -160,13 +160,6 @@ u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int io_busy) > > } > > EXPORT_SYMBOL_GPL(get_cpu_idle_time); > > > > -__weak void arch_set_freq_scale(const struct cpumask *cpus, > > - unsigned long cur_freq, > > - unsigned long max_freq) > > -{ > > -} > > -EXPORT_SYMBOL_GPL(arch_set_freq_scale); > > - > > Why can't we have this anymore ? Because it is a macro now instead of a routine > for ARM ?
Yes, instead of having a strong counterpart in arch_topology.c to be used for both arm64 and arm, I separated the definitions of the arch_set_freq_scale symbol in each architecture's topology.h in order to be filtered if needed (as is the case for arm's BL_SWITCHER).
I could have kept either this weak stub definition or the stub that is now in cpufreq.h under "#ifndef arch_set_freq_scale", but I chose the latter as it's more aligned with the other architectural functions referenced in the commit message.
So this patch has both the purpose of enabling a nicer filtering of frequency invariance for BL_SWITCHER but also follows the definition pattern of the other functions so we don't keep having two mindsets when working with them.
Thanks, Ionela.
| |