linux-kernel - [PATCH 1/6] cpufreq: Don't check for max_transition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <9924a30ffcce1b83fd6b3d199753a039a1d6f5ef.1498733506.git.viresh.kumar@linaro.org>
Date:   Thu, 29 Jun 2017 16:29:04 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Rafael Wysocki <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     linux-pm@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: [PATCH 1/6] cpufreq: Don't check for max_transition_latency

This check is there only for drivers that set transition_latency to
CPUFREQ_ETERNAL. And the "max_transition_latency" field is only set for
ondemand and conservative governors (i.e. This code doesn't run for
schedutil governor).

With CPUFREQ_ETERNAL, transition latency becomes around 4 seconds (yeah
its practically impossible). But even then there is nothing particular
in the governor's code that will not function if the latency is over
10ms (TRANSITION_LATENCY_LIMIT). Why disable use of the governor
completely ?

And if its about falling back to the performance governor for such
platforms, then we aren't doing the same for schedutil governor.

This patch get rids of this particular check and let platforms decide if
they want to use legacy governors or not.

Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
---
 drivers/cpufreq/cpufreq.c | 14 --------------
 include/linux/cpufreq.h   |  3 ---
 2 files changed, 17 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6e7424d12de9..34dbbf3122c8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1988,20 +1988,6 @@ static int cpufreq_init_governor(struct cpufreq_policy *policy)
 	if (!policy->governor)
 		return -EINVAL;
 
-	if (policy->governor->max_transition_latency &&
-	    policy->cpuinfo.transition_latency >
-	    policy->governor->max_transition_latency) {
-		struct cpufreq_governor *gov = cpufreq_fallback_governor();
-
-		if (gov) {
-			pr_warn("%s governor failed, too long transition latency of HW, fallback to %s governor\n",
-				policy->governor->name, gov->name);
-			policy->governor = gov;
-		} else {
-			return -EINVAL;
-		}
-	}
-
 	if (!try_module_get(policy->governor->owner))
 		return -EINVAL;
 
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 905117bd5012..0818bdc3ebf2 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -487,9 +487,6 @@ static inline unsigned long cpufreq_scale(unsigned long old, u_int div,
  * polling frequency is 1000 times the transition latency of the processor. The
  * ondemand governor will work on any processor with transition latency <= 10ms,
  * using appropriate sampling rate.
- *
- * For CPUs with transition latency > 10ms (mostly drivers with CPUFREQ_ETERNAL)
- * the ondemand governor will not work. All times here are in us (microseconds).
  */
 #define MIN_SAMPLING_RATE_RATIO		(2)
 #define LATENCY_MULTIPLIER		(1000)
-- 
2.13.0.71.gd7076ec9c9cb