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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231025080910.3245690-1-zengheng4@huawei.com>
Date:   Wed, 25 Oct 2023 16:09:10 +0800
From:   Zeng Heng <zengheng4@...wei.com>
To:     <viresh.kumar@...aro.org>, <rafael@...nel.org>
CC:     <liwei391@...wei.com>, <linux-pm@...r.kernel.org>,
        <xiexiuqi@...wei.com>, <wangxiongfeng2@...wei.com>,
        <linux-kernel@...r.kernel.org>
Subject: [PATCH -next] cpufreq: userspace: Keep the current frequency when set userspace policy

When switching to the userspace policy, if the current frequency is within
the range of policy's min and max values, the current frequency value
should be remained. The .limit() function is called when changing governor
or updating governor limits, so in both cases, there is no need to update
frequency if the current frequency does not exceed the threshold.

Additionally, when changing to userspace governor, the default value of
set_speed is set by reading the current frequency of the CPU, but there
is inevitable error between the frequency coming from .get_rate() interface
and the actual working frequency. Consequently, when switching to userspace
policy, keeping the current frequency can avoid unexpected changes.

Signed-off-by: Zeng Heng <zengheng4@...wei.com>
---
 drivers/cpufreq/cpufreq_userspace.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index 2c42fee76daa..fe55a7bb663c 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -117,9 +117,7 @@ static void cpufreq_userspace_policy_limits(struct cpufreq_policy *policy)
 	else if (policy->min > userspace->setspeed)
 		__cpufreq_driver_target(policy, policy->min,
 					CPUFREQ_RELATION_L);
-	else
-		__cpufreq_driver_target(policy, userspace->setspeed,
-					CPUFREQ_RELATION_L);
+	/* Otherwise, keep the current frequency. */

 	mutex_unlock(&userspace->mutex);
 }
--
2.25.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ