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>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ny7npyivbpk3zaf3dm6h3ves4azp75hzmrqmpiex3nauuzrzmt@zf3rto3vrjbq>
Date: Mon, 19 Jan 2026 13:58:21 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Pengjie Zhang <zhangpengjie2@...wei.com>
Cc: rafael@...nel.org, 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, wangzhi12@...wei.com
Subject: Re: [RFC PATCH] cpufreq: userspace: make scaling_setspeed return the
 actual requested frequency

On 16-01-26, 17:46, Pengjie Zhang wrote:
> 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)

Looks okay to me.

Acked-by: Viresh Kumar <viresh.kumar@...aro.org>

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ