On Sunday, January 25, 2015 06:54:27 PM Viresh Kumar wrote:
On 2 January 2015 at 12:34, Viresh Kumar viresh.kumar@linaro.org wrote:
In most of the cases cpufreq wouldn't be disabled and this adds unnecessary delay for its users. In the case if cpufreq is really disabled, then the per-cpu variable will also return NULL and things will continue working as is. Remove this unnecessary check.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
drivers/cpufreq/cpufreq.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 14d637a28dd8..62c6a0b8b0d1 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -202,9 +202,6 @@ struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu) struct cpufreq_policy *policy = NULL; unsigned long flags;
if (cpufreq_disabled())return NULL;if (!down_read_trylock(&cpufreq_rwsem)) return NULL;@@ -229,9 +226,6 @@ EXPORT_SYMBOL_GPL(cpufreq_cpu_get);
void cpufreq_cpu_put(struct cpufreq_policy *policy) {
if (cpufreq_disabled())return;kobject_put(&policy->kobj); up_read(&cpufreq_rwsem);}
@Rafael: Are you fine with this patch as is? I meant, you just left it for rebase conflict or because you want it to be part of the WARN() you suggested?
It depended on [15/17] that I didn't apply.
The WARN here might not be a good idea as this can be called by users while cpufreq is disabled. But we don't need this check because of the reasons I mentioned in commit log.
I'm not sure which commit log are you talking about, this one or the [15/17] one?