Re: [PATCH] Documentation: admin-guide: pm: cpufreq: fix sampling_rate example command

[Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>]

On 6/21/2026 11:52 AM, Randy Dunlap wrote:
> 
> 
> On 6/20/26 7:25 PM, wangxiaodong wrote:
>> The example shell command for setting ondemand's sampling_rate wraps an
>> arithmetic expansion $((...)) in command-substitution backticks. The
>> arithmetic result is then executed as a command, which fails and writes
>> an empty value. Drop the surrounding backticks so the computed value is
>> passed to echo as intended.
>>
>> Signed-off-by: wangxiaodong <wangxiaodong827546786@gmail.com>
>> ---
>>   Documentation/admin-guide/pm/cpufreq.rst | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
>> index 8831cface585..34baf20cc202 100644
>> --- a/Documentation/admin-guide/pm/cpufreq.rst
>> +++ b/Documentation/admin-guide/pm/cpufreq.rst
>> @@ -497,7 +497,7 @@ This governor exposes the following tunables:
>>   	represented by it to be 1.5 times as high as the transition latency
>>   	(the default)::
>>   
>> -	# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2))` > ondemand/sampling_rate
>> +	# echo $(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
> 
> Ugh. Thanks.
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> 
> and possibly:
> Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")


Thanks Randy,

Just to back up Randy's Fixes suggestion, the line evolved as follows
(most recent first):

2025/04/04 e54ac586674d:  #echo `$((.. * 3 / 2))` >  (trailing ` added)
2024/10/17 29dcbea92460:  #echo `$((.. * 3 / 2))  >  (still dangling `)
2017/03/13 2a0e49279850:  #echo `$((.. * 750 / 1000)) > (dangling leading `)

The stray backtick can be traced back to 2a0e49279850, but it was just a
dangling backtick then. The closed command-substitution form fixed here
was only reached after e54ac586674d added the trailing backtick. Note
that the "750/1000 -> 3/2" change in 29dcbea92460 was not just a doc
edit: it reflects an actual change in the kernel's behaviour. So on the
older trees the underlying logic - and hence this documented example -
is genuinely different, and this patch wouldn't apply cleanly there
anyway. Pointing Fixes at 2a0e49279850 therefore wouldn't help
backports.

So using

Fixes: e54ac586674d ("cpufreq: editing corrections to cpufreq.rst")

seems reasonable.

Either way, the fix is fine to me:

Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>




> 
>>   
>>   ``up_threshold``
>>   	If the estimated CPU load is above this value (in percent), the governor
> 


-- 
Thx and BRs,
Zhongqiu Han