linux-kernel - Re: [PATCH v5 10/11] cpufreq: CPPC: make scaling_min/max_freq read-only when auto

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7639de1-a5b6-40c1-9d12-1606b558997c@nvidia.com>
Date: Thu, 8 Jan 2026 19:31:09 +0530
From: Sumit Gupta <sumitg@...dia.com>
To: "zhenglifeng (A)" <zhenglifeng1@...wei.com>, rafael@...nel.org,
 viresh.kumar@...aro.org, lenb@...nel.org, robert.moore@...el.com,
 corbet@....net, pierre.gondois@....com, rdunlap@...radead.org,
 ray.huang@....com, gautham.shenoy@....com, mario.limonciello@....com,
 perry.yuan@....com, ionela.voinescu@....com, zhanjie9@...ilicon.com,
 linux-pm@...r.kernel.org, linux-acpi@...r.kernel.org,
 linux-doc@...r.kernel.org, acpica-devel@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Cc: linux-tegra@...r.kernel.org, treding@...dia.com, jonathanh@...dia.com,
 vsethi@...dia.com, ksitaraman@...dia.com, sanjayc@...dia.com,
 nhartman@...dia.com, bbasu@...dia.com, sumitg@...dia.com
Subject: Re: [PATCH v5 10/11] cpufreq: CPPC: make scaling_min/max_freq
 read-only when auto_sel enabled


On 26/12/25 08:56, zhenglifeng (A) wrote:
> External email: Use caution opening links or attachments
>
>
> On 2025/12/23 20:13, Sumit Gupta wrote:
>> When autonomous selection (auto_sel) is enabled, the hardware controls
>> performance within min_perf/max_perf register bounds making the
>> scaling_min/max_freq effectively read-only.
>>
>> Enforce this by setting policy limits to min/max_perf bounds in
>> cppc_verify_policy(). Users must use min_perf/max_perf sysfs interfaces
>> to change performance limits in autonomous mode.
>>
>> Signed-off-by: Sumit Gupta <sumitg@...dia.com>
>> ---
>>   drivers/cpufreq/cppc_cpufreq.c | 32 +++++++++++++++++++++++++++++++-
>>   1 file changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index b1f570d6de34..b3da263c18b0 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -305,7 +305,37 @@ static unsigned int cppc_cpufreq_fast_switch(struct cpufreq_policy *policy,
>>
>>   static int cppc_verify_policy(struct cpufreq_policy_data *policy)
>>   {
>> -     cpufreq_verify_within_cpu_limits(policy);
>> +     unsigned int min_freq = policy->cpuinfo.min_freq;
>> +     unsigned int max_freq = policy->cpuinfo.max_freq;
>> +     struct cpufreq_policy *cpu_policy;
>> +     struct cppc_cpudata *cpu_data;
>> +     struct cppc_perf_caps *caps;
>> +
>> +     cpu_policy = cpufreq_cpu_get(policy->cpu);
> Better to use:
>
>          struct cpufreq_policy *cpu_policy __free(put_cpufreq_policy) = cpufreq_cpu_get(policy->cpu);

Will use this in v6.


>> +     if (!cpu_policy)
>> +             return -ENODEV;
>> +
>> +     cpu_data = cpu_policy->driver_data;
>> +     caps = &cpu_data->perf_caps;
> cpu_policy, cpu_data and cpas are only used in the if branch. Just put them
> in it.

Can move caps inside the if branch.
cpu_policy and cpu_data can't be moved inside because we need
perf_ctrls.auto_sel to evaluate the condition itself.

>> +
>> +     if (cpu_data->perf_ctrls.auto_sel) {
>> +             u32 min_perf, max_perf;
>> +
>> +             /*
>> +              * Set policy limits to HW min/max_perf bounds. In autonomous
>> +              * mode, scaling_min/max_freq is effectively read-only.
>> +              */
>> +             min_perf = cpu_data->perf_ctrls.min_perf ?:
>> +                        caps->lowest_nonlinear_perf;
>> +             max_perf = cpu_data->perf_ctrls.max_perf ?: caps->nominal_perf;
>> +
>> +             policy->min = cppc_perf_to_khz(caps, min_perf);
>> +             policy->max = cppc_perf_to_khz(caps, max_perf);
>> +     } else {
>> +             cpufreq_verify_within_limits(policy, min_freq, max_freq);
> Why not still using cpufreq_verify_within_cpu_limits()?

Will change to use it in v6.

Thank you,
Sumit Gupta

>> +     }
>> +
>> +     cpufreq_cpu_put(cpu_policy);
>>        return 0;
>>   }
>>