linux-kernel - Re: [RFC PATCH] cpufreq: userspace: Add fast-switch support for userspace

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: <a3a4852f-5d22-4440-ac0c-f24f97d3b3d4@arm.com>
Date: Tue, 10 Dec 2024 10:20:40 +0000
From: Christian Loehle <christian.loehle@....com>
To: Xuewen Yan <xuewen.yan94@...il.com>
Cc: Xuewen Yan <xuewen.yan@...soc.com>, rafael@...nel.org,
 viresh.kumar@...aro.org, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, guohua.yan@...soc.com, ke.wang@...soc.com
Subject: Re: [RFC PATCH] cpufreq: userspace: Add fast-switch support for
 userspace

On 12/10/24 03:27, Xuewen Yan wrote:
> On Mon, Dec 9, 2024 at 6:36 PM Christian Loehle
> <christian.loehle@....com> wrote:
>>
>> On 12/9/24 08:14, Xuewen Yan wrote:
>>> Now, the userspace governor does not support userspace,
>>> if the driver only use the fast-switch and not add target_index(),
>>
>> Which driver does that? Is that actually valid?
>> No mainline driver from what I can see.
>>
> 
> Yes, indeed no mainline driver, It's on our own driver.

Fair enough. 
There seems to be handling for that case in cpufreq anyway.

> 
>>> it will cause uerspace not work.
>>
>> s/uerspace/userspace
>> to not work?
>>
>>> So add fast-switch support for userspace governor.
>>>
>>> Co-developed-by: Guohua Yan <guohua.yan@...soc.com>
>>> Signed-off-by: Guohua Yan <guohua.yan@...soc.com>
>>> Signed-off-by: Xuewen Yan <xuewen.yan@...soc.com>
>>> ---
>>>  drivers/cpufreq/cpufreq_userspace.c | 35 +++++++++++++++++++++++++----
>>>  1 file changed, 31 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c
>>> index 2c42fee76daa..3a99197246ed 100644
>>> --- a/drivers/cpufreq/cpufreq_userspace.c
>>> +++ b/drivers/cpufreq/cpufreq_userspace.c
>>> @@ -21,6 +21,30 @@ struct userspace_policy {
>>>       struct mutex mutex;
>>>  };
>>>
>>> +static int cpufreq_userspace_target_freq(struct cpufreq_policy *policy,
>>> +                     unsigned int target_freq, unsigned int relation)
>>> +{
>>> +     int ret;
>>
>> not really necessary
> 
> In cpufreq_set(), we need the return value.

Sorry for not being clear enough, I suggested rewriting it
like this, although personal preference.

---
static int cpufreq_userspace_target_freq(struct cpufreq_policy *policy,
			unsigned int target_freq, unsigned int relation)
{
	unsigned int idx;

	if (!policy->fast_switch_enabled)
		return __cpufreq_driver_target(policy, target_freq, relation);

	target_freq = clamp_val(target_freq, policy->min, policy->max);
	if (!policy->freq_table)
		return target_freq;

	idx = cpufreq_frequency_table_target(policy, target_freq, relation);
	policy->cached_resolved_idx = idx;
	policy->cached_target_freq = target_freq;
	return !cpufreq_driver_fast_switch(policy, policy->freq_table[idx].frequency);
}