linux-kernel - Re: [PATCH v4] soc: tegra: fuse: speedo-tegra210: Update speedo ids

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: <43f48d63-7bcb-47f5-814e-dd95fdf0b246@nvidia.com>
Date: Tue, 30 Sep 2025 15:54:54 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: webgeek1234@...il.com, Thierry Reding <thierry.reding@...il.com>,
 Joseph Lo <josephl@...dia.com>, Stephen Boyd <sboyd@...nel.org>
Cc: Thierry Reding <treding@...dia.com>, linux-tegra@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] soc: tegra: fuse: speedo-tegra210: Update speedo ids


On 23/09/2025 17:58, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@...il.com>
> 
> Existing code only sets cpu and gpu speedo ids 0 and 1. The cpu dvfs
> code supports 11 ids and nouveau supports 5. This aligns with what the
> downstream vendor kernel supports. Align skus with the downstream list.
> 
> The Tegra210 CVB tables were added in the first referenced fixes commit.
> Since then, all Tegra210 socs have tried to scale to 1.9 GHz, when the
> supported devkits are only supposed to scale to 1.5 or 1.7 GHZ.
> Overclocking should not be the default state.
> 
> Fixes: 2b2dbc2f94e5 ("clk: tegra: dfll: add CVB tables for Tegra210")
> Fixes: 579db6e5d9b8 ("arm64: tegra: Enable DFLL support on Jetson Nano")
> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> ---
> The Tegra210 CVB tables were added in commit 2b2dbc2f94e5. Since then,
> all Tegra210 socs have tried to scale the cpu to 1.9 GHz, when the
> supported devkits are only supposed to scale to 1.5 or 1.7 GHZ.
> Overclocking should not be the default state.
> ---
> Changes in v4:
> - Check soc chip revision instead of speedo revision in speedo id
>    conversion
> - Link to v3: https://lore.kernel.org/r/20250903-tegra210-speedo-v3-1-73e09e0fbb36@gmail.com
> 
> Changes in v3:
> - Drop all patches related to limiting cpu frequency from a dt property
> - Link to v2: https://lore.kernel.org/r/20250903-tegra210-speedo-v2-0-89e6f86b8942@gmail.com
> 
> Changes in v2:
> - Define units in patch 1
> - Update patch 1 commit message to better explain the need
> - Pull all downstream sku's into patch 2, which eliminates patch 3
> - Update patch 4 commit message to indicate the limit is due to thermal
>    constraints.
> - Link to v1: https://lore.kernel.org/r/20250816-tegra210-speedo-v1-0-a981360adc27@gmail.com
> ---
>   drivers/soc/tegra/fuse/speedo-tegra210.c | 62 ++++++++++++++++++++++----------
>   1 file changed, 43 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/soc/tegra/fuse/speedo-tegra210.c b/drivers/soc/tegra/fuse/speedo-tegra210.c
> index 695d0b7f9a8abe53c497155603147420cda40b63..a8cc3632977230fbfda0f8c3bfa7b7b25c2378fe 100644
> --- a/drivers/soc/tegra/fuse/speedo-tegra210.c
> +++ b/drivers/soc/tegra/fuse/speedo-tegra210.c
> @@ -65,27 +65,51 @@ static void __init rev_sku_to_speedo_ids(struct tegra_sku_info *sku_info,
>   	sku_info->gpu_speedo_id = 0;
>   	*threshold = THRESHOLD_INDEX_0;
>   
> -	switch (sku) {
> -	case 0x00: /* Engineering SKU */
> -	case 0x01: /* Engineering SKU */
> -	case 0x07:
> -	case 0x17:
> -	case 0x27:
> -		if (speedo_rev >= 2)
> +	if (sku_info->revision >= TEGRA_REVISION_A02) {

The dowstream changes just have 'revision == A02' here and not greater 
or equal to. That said, I believe that A02 is the greatest revision of 
this device and so this should be fine. Thierry can make a final call, 
but otherwise ...

Reviewed-by: Jon Hunter <jonathanh@...dia.com>

Cheers
Jon

-- 
nvpublic