linux-kernel - Re: [PATCH 1/2] cpufreq: Export 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: <CALHNRZ9Yr4KJAz8NtfA_jjYyfUSNC1M=H57iCJXgX+dKJsr5eA@mail.gmail.com>
Date: Mon, 21 Apr 2025 00:55:42 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Thierry Reding <thierry.reding@...il.com>, 
	Jonathan Hunter <jonathanh@...dia.com>, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH 1/2] cpufreq: Export disable_cpufreq()

On Mon, Apr 21, 2025 at 12:44 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 20-04-25, 15:42, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@...il.com>
> >
> > This is used by the tegra124-cpufreq driver.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> > ---
> >  drivers/cpufreq/cpufreq.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 0cf5a320bb5e864709b259249fb1af8bfbc0b04b..78cddc78ee98630f99ccc332c64c94f437297177 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -109,6 +109,7 @@ void disable_cpufreq(void)
> >  {
> >       off = 1;
> >  }
> > +EXPORT_SYMBOL_GPL(disable_cpufreq);
> >  static DEFINE_MUTEX(cpufreq_governor_mutex);
> >
> >  bool have_governor_per_policy(void)
>
> I didn't realize earlier that tegra124 uses this call directly. I
> think this call was rather meant for other parts of the kernel
> (non-cpufreq drivers) to disable the frequency switching. It may not
> fit really well here.
>
> Instead what Tegra's driver could do is remove cpufreq_dt_pdev, which
> shall lead to unregistering the cpufreq driver completely.
This makes a lot more sense. I will look into that and upload a v2
swapping this patch for that once I verify it.

Sincerely,
Aaron