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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALHNRZ8oaGaAhMVVzfeNf+M+-OvMnCnMd-fRdffmOSTBZiEXCQ@mail.gmail.com>
Date: Mon, 25 Aug 2025 00:08:55 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: webgeek1234@...il.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 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
> cluster, but one of the A57 cores also exhibits this behaviour. If the
> value is initialized to match what is read by the downstream vendor
> kernel, scaling works as expected. I have never seen this value be
> anything other than 35, so it should be a relatively safe assumption.
>
> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> ---
>  drivers/cpufreq/tegra186-cpufreq.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
> index cbabb726c6645d2e5f1857a47e5643c8552d1933..f017f903c6843f1881e8311753f6269637c6bc69 100644
> --- a/drivers/cpufreq/tegra186-cpufreq.c
> +++ b/drivers/cpufreq/tegra186-cpufreq.c
> @@ -115,6 +115,11 @@ static unsigned int tegra186_cpufreq_get(unsigned int cpu)
>
>         edvd_offset = data->cpus[policy->cpu].edvd_offset;
>         ndiv = readl(data->regs + edvd_offset) & EDVD_CORE_VOLT_FREQ_F_MASK;
> +       if (ndiv == 0) {
> +               dev_warn_once(get_cpu_device(policy->cpu),
> +                        "Scaling registers invalid, using expected values");
> +               ndiv = 35;
> +       }
>         cluster_id = data->cpus[policy->cpu].bpmp_cluster_id;
>         cluster = &data->clusters[cluster_id];
>         cpufreq_cpu_put(policy);
>
> ---
> base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
> change-id: 20250824-tegra186-cpufreq-ndiv-bc97a22814a9
>
> Best regards,
> --
> Aaron Kling <webgeek1234@...il.com>
>
>

I tried to open a discussion about this issue on the mailing list [0],
but well over two months later, no responses have been given. I know
this isn't an ideal solution, but in lieu of better knowledge of
what's happening, this is the best I have. And this unblocks scaling
the denver cores on tegra186.

Aaron

[0] https://lore.kernel.org/linux-tegra/CALHNRZ98_gh5dKw_GoayG4ieU3TWYAFFt29=495g4+dNLzwjbg@mail.gmail.com/