linux-kernel - Re: [PATCH] cpufreq: tegra186: Default divider to 35 if register read fails

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALHNRZ8HfD+ftrQSJJLE_vsxGq3xyPxD3=m6Xg=LQKXR1nZvPQ@mail.gmail.com>
Date: Tue, 26 Aug 2025 02:17:42 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Mikko Perttunen <mperttunen@...dia.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>, 
	Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, 
	linux-pm@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: tegra186: Default divider to 35 if register read fails

On Mon, Aug 25, 2025 at 11:48 PM Mikko Perttunen <mperttunen@...dia.com> wrote:
>
> On Monday, August 25, 2025 2:08 PM Aaron Kling wrote:
> > On Mon, Aug 25, 2025 at 12:03 AM Aaron Kling via B4 Relay
> >
> > <devnull+webgeek1234.gmail.com@...nel.org> wrote:
> > > From: Aaron Kling <webgeek1234@...il.com>
> > >
> > > Several of the cores fail to read any registers and thus fail to
> > > initialize cpufreq. With shared policies, this only affects the Denver
>
> By failing to read any registers, do you just mean that they read as 0?

Yes, that is correct.

> I suspect the issue may be that the EDVD_COREx_VOLT_FREQ registers are just
> used to request VF transitions. If no one has requested anything, the register
> will be at its reset value, zero.
>
> AIUI, in downstream, the driver retrieves the CPU clock rate by measuring it
> instead of calculating it from an NDIV value, hence it would not run into this
> issue. I think the conclusion would be that if the register reads as zero, we
> cannot assume any clock rate. Is it possible to tell the cpufreq framework
> that we don't know the rate and it should ask us to set the rate to something?
> Or otherwise at probe time do this by ourselves.

This is a very helpful pointer. If I initialize all cores to their
respective base frequencies during probe, the subsequent get's work as
intended. I want to do a little more verification before sending in
another patch as I also found another issue with my previous shared
policy patch. I will submit a new series once that is done, so this
patch can be abandoned.

Aaron