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] [day] [month] [year] [list]

Message-ID: <CALHNRZ-48T+ZuhTLeQb5w1sAdTtnMP6LX=MrWiE+Qze4tii4FQ@mail.gmail.com>
Date: Mon, 20 Oct 2025 14:33:36 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Thierry Reding <thierry.reding@...il.com>, Joseph Lo <josephl@...dia.com>, 
	Stephen Boyd <sboyd@...nel.org>, 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 Tue, Sep 30, 2025 at 9:55 AM Jon Hunter <jonathanh@...dia.com> wrote:
>
>
> 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 ...

Reminder to review or pick up this patch.

Aaron