linux-kernel - [RFC PATCH] cpufreq: userspace: make scaling_setspeed return the actual requested frequency

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: <20260116094623.2980031-1-zhangpengjie2@huawei.com>
Date: Fri, 16 Jan 2026 17:46:23 +0800
From: Pengjie Zhang <zhangpengjie2@...wei.com>
To: <rafael@...nel.org>, <viresh.kumar@...aro.org>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<zhanjie9@...ilicon.com>, <zhenglifeng1@...wei.com>, <lihuisong@...wei.com>,
	<yubowen8@...wei.com>, <linhongye@...artners.com>, <linuxarm@...wei.com>,
	<jonathan.cameron@...wei.com>, <zhangpengjie2@...wei.com>,
	<wangzhi12@...wei.com>
Subject: [RFC PATCH] cpufreq: userspace: make scaling_setspeed return the actual requested frequency

According to the Linux kernel ABI documentation for 'scaling_setspeed':
  "It returns the last frequency requested by the governor (in kHz) or
   can be written to in order to set a new frequency for the policy."

However, the current implementation of show_speed() returns 'policy->cur'.
'policy->cur' represents the frequency after the driver has
resolved the request against the hardware frequency table and applied
policy limits (min/max).

This creates a discrepancy between the documentation/user expectation and
the actual code behavior. For instance:

1. User writes a value to 'scaling_setspeed' that is not in the OPP table
   (e.g., user asks for A, driver rounds it to B).
2. User reads 'scaling_setspeed'.
3. Code returns B ('policy->cur').
4. User expects A (the "frequency requested"), but gets B.

This patch changes show_speed() to return 'userspace->setspeed', which
stores the actual value last requested by the user. This restores the
read/write symmetry of the attribute and aligns the code with the ABI
description.

The effective frequency can still be observed via 'scaling_cur_freq' or
'cpuinfo_cur_freq', preserving the distinction between "what was
requested" (setspeed) and "what is effective" (cur_freq).

Signed-off-by: Pengjie Zhang <zhangpengjie2@...wei.com>
---
 drivers/cpufreq/cpufreq_userspace.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
index 77d62152cd38..4bd62e6c5c51 100644
--- a/drivers/cpufreq/cpufreq_userspace.c
+++ b/drivers/cpufreq/cpufreq_userspace.c
@@ -49,7 +49,9 @@ static int cpufreq_set(struct cpufreq_policy *policy, unsigned int freq)

 static ssize_t show_speed(struct cpufreq_policy *policy, char *buf)
 {
-	return sprintf(buf, "%u\n", policy->cur);
+	struct userspace_policy *userspace = policy->governor_data;
+
+	return sprintf(buf, "%u\n", userspace->setspeed);
 }

 static int cpufreq_userspace_policy_init(struct cpufreq_policy *policy)
-- 
2.33.0