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

From: Rafael J. Wysocki (Intel)

Date: Mon Jul 06 2026 - 14:57:58 EST


On Sun, Jun 21, 2026 at 7:57 AM Zhongqiu Han
<zhongqiu.han@xxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxx>
> >> ---
> >> 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@xxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxxx>

Applied as 7.3 material, thanks!