linux-kernel - Re: [PATCH v4 1/2] cpufreq: tegra124: Remove use of disable

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: <49e7d006-e9cb-49da-a4cb-b73a08f6b792@nvidia.com>
Date: Tue, 20 May 2025 10:53:29 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: webgeek1234@...il.com, "Rafael J. Wysocki" <rafael@...nel.org>,
 Thierry Reding <thierry.reding@...il.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 1/2] cpufreq: tegra124: Remove use of disable_cpufreq

On 19/05/2025 11:17, Viresh Kumar wrote:
> On 09-05-25, 12:04, Jon Hunter wrote:
>>> diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
>>> index 514146d98bca2d8aa59980a14dff3487cd8045f6..bc0691e8971f9454def37f489e4a3e244100b9f4 100644
>>> --- a/drivers/cpufreq/tegra124-cpufreq.c
>>> +++ b/drivers/cpufreq/tegra124-cpufreq.c
>>> @@ -168,7 +168,10 @@ static int __maybe_unused tegra124_cpufreq_resume(struct device *dev)
>>>    disable_dfll:
>>>    	clk_disable_unprepare(priv->dfll_clk);
>>>    disable_cpufreq:
>>> -	disable_cpufreq();
>>> +	if (!IS_ERR(priv->cpufreq_dt_pdev)) {
>>> +		platform_device_unregister(priv->cpufreq_dt_pdev);
>>> +		priv->cpufreq_dt_pdev = ERR_PTR(-ENODEV);
>>> +	}
>>
>> So you are proposing to unregister the device in resume? That seems odd. I
>> see there is no remove for this driver, but I really don't see the value in
>> this.
> 
> This is the failure path and the driver is trying to disable itself
> here. Instead of using the disable_cpufreq() (which isn't designed for
> this usecase), I suggested removing the device itself as the driver
> will be unusable after this anyway.

I understand, but this seems odd. It would be odd that the device may 
just disappear after resuming from suspend if it fails to resume. I have 
not seen this done for other drivers that fail to resume. Presumably 
this is not the only CPU Freq driver that could fail to resume either?

It makes the code messy because now we have more than one place where 
the device could be unregistered.

Jon

-- 
nvpublic