Re: [PATCH] cpufreq: Documentation: fix freq_step description

[Zhongqiu Han]

On 5/29/2026 7:11 PM, Pengjie Zhang wrote:
> The conservative governor documentation incorrectly states that setting
> freq_step to 0 will use the default 5% frequency step. In reality, since
> the governor's initial implementation
> commit b9170836d1aa ("[CPUFREQ] Conservative cpufreq governer"),
> freq_step=0 has always caused the governor to skip frequency updates
> entirely.

Hi Pengjie,

Thanks for the patch.

The documentation fix looks correct: in the current code,
cs_dbs_update() has an early goto out when freq_step == 0, which skips
the call to get_freq_step() and all subsequent frequency change logic.

However, the commit message's historical claim appears to be inaccurate.
In the original implementation (b9170836d1aa), freq_step=0 had
asymmetric behavior: frequency decreases were skipped (early return),
but frequency increases still used the hardcoded 5% fallback (freq_step
= 5 after the unlikely(freq_step == 0) check).

If so, would it make sense to remove/update the historical claim to
avoid the incorrect historical claim?

> Correct the documentation to reflect the actual behavior: freq_step=0
> disables frequency changes by the governor entirely.
>
> Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
> Signed-off-by: Pengjie Zhang <zhangpengjie2@xxxxxxxxxx>
> ---
>   Documentation/admin-guide/pm/cpufreq.rst | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
> index dbe6d23a5d67..98c724d49047 100644
> --- a/Documentation/admin-guide/pm/cpufreq.rst
> +++ b/Documentation/admin-guide/pm/cpufreq.rst
> @@ -586,8 +586,8 @@ This governor exposes the following tunables:
>   	100 (5 by default).
>   
>   	This is how much the frequency is allowed to change in one go.  Setting
> -	it to 0 will cause the default frequency step (5 percent) to be used
> -	and setting it to 100 effectively causes the governor to periodically
> +	it to 0 disables frequency changes by the governor entirely and setting
> +	it to 100 effectively causes the governor to periodically
>   	switch the frequency between the ``scaling_min_freq`` and
>   	``scaling_max_freq`` policy limits.
>   


--
Thx and BRs,
Zhongqiu Han