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: <CALHNRZ-uA6vHYbb5UdDvhRrNy5j2jyds4iTsiOxc6O=2nnedbg@mail.gmail.com>
Date: Mon, 30 Jun 2025 13:43:40 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Jon Hunter <jonathanh@...dia.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 Thu, Jun 5, 2025 at 5:51 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 05-06-25, 11:34, Jon Hunter wrote:
> > I think that would be fine. Given that the tegra124-cpufreq driver is the
> > parent, if it fails to resume, then I assume that cpufreq-dt driver would
> > not resume either?
>
> There is no resume interface in the cpufreq-dt driver, it is the cpufreq core
> which resumes to doing DVFS and I think it will try to do DVFS even if tegra's
> driver failed.

In my opinion, I'm thinking the original flow makes more sense. If
resume fails, disable cpufreq. Then the subsystem doesn't keep trying
and failing and causing who knows what kind of havoc. But if that's
still not desired, what should I do to get this moving again? Just
drop the error handling entirely, as suggested?

Aaron