All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Thierry Reding <thierry.reding@kernel.org>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	 Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <treding@nvidia.com>,
	linux-tegra@vger.kernel.org,  linux-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms
Date: Mon, 22 Jun 2026 02:33:25 -0700	[thread overview]
Message-ID: <ajj-GEpENo8-7cxx@gmail.com> (raw)
In-Reply-To: <ajjfgOLpDXuVHpI0@orome>

Hello Thierry,

On Mon, Jun 22, 2026 at 09:24:03AM +0200, Thierry Reding wrote:
> > Have you had a chance to look at this one? This is showing up in my
> > Grace all the time.
> 
> Yeah, sorry for the delay. You're right in that we now get the warning
> until we end up calling tegra_read_chipid(). However, I don't think the
> Fixes: reference is right. I think this started showing up after:
> 
>   8b8ee2e56f95 ("soc/tegra: Use ARM SMCCC to get chip ID, revision, and platform info")

Ack!

> I don't think we accounted for tegra_read_straps() in that case and I
> suspect that we're not seeing this elsewhere because we do end up
> calling tegra_read_chipid() earlier in DT systems whereas for ACPI it
> might only get called at a later point, if at all.
> 
> There's also this patch:
> 
>   https://lore.kernel.org/linux-tegra/20260514051252.2401568-1-kkartik@nvidia.com/
> 
> IIUC, that's the only place where tegra_read_straps() gets called on
> ACPI systems. Would you mind testing that patch (without the one that
> we're currently discussing) to confirm that that's the only callsite?

Sure, I've just tested it, and it doesn't hit the problematic path.
Thanks for pointing it out.

> It doesn't really matter either way, because applying your fix here is
> the right thing to do, but it'd still be useful as a data point.

Agreed, they seem independent. This patch fixes the issue, while
Kartik's patch avoids hitting it.

> If you don't have any objections, I'm going to replace the Fixes: line,
> but otherwise this patch looks good.

Ack!

> Also, I'm going to check if we can get some better coverage in our daily
> testing for the ACPI platforms. Do you happen to run any daily tests on
> your systems for linux-next?

Yes, I use my Grace machine for development, and I am usually on
linux-next, so, I get these crazy issues from time to time.

Thanks for the reply,
--breno

      reply	other threads:[~2026-06-22  9:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-04 10:36 [PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms Breno Leitao
2026-06-15 15:32 ` Breno Leitao
2026-06-22  7:24   ` Thierry Reding
2026-06-22  9:33     ` Breno Leitao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ajj-GEpENo8-7cxx@gmail.com \
    --to=leitao@debian.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@kernel.org \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.