diff options
| author | Pengjie Zhang <zhangpengjie2@huawei.com> | 2026-01-16 17:46:23 +0800 |
|---|---|---|
| committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2026-01-28 22:24:32 +0100 |
| commit | cc764d3bbd545d7d6f5f66ac678ffc522d75f0f9 (patch) | |
| tree | f8dfd96459defa841ce397b3fa33ca6e0c1227a8 /include | |
| parent | 4a1cf5ed51b1b6049d7771d2e77789b99dafc8ae (diff) | |
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@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: lihuisong@huawei.com
Link: https://patch.msgid.link/20260116094623.2980031-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
