[PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms

[PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms

[Breno Leitao]

My Grace host started to show this warning:
  WARNING: drivers/soc/tegra/fuse/tegra-apbmisc.c:120 at tegra_read_straps
   tegra30_fuse_add_randomness
   tegra30_fuse_init
   tegra_fuse_probe

tegra_read_straps() warns when the static "chipid" cache is still zero,
using it as a proxy for "APBMISC has been initialised". However chipid
is only ever populated lazily by tegra_read_chipid() when it reads the
APBMISC register.

Guard on apbmisc_base instead, which is set unconditionally in
tegra_init_apbmisc_resources() for all platforms and is already the
sentinel used by tegra_read_chipid().

Fixes: c71f213fa5af ("soc/tegra: fuse: Warn if straps are not ready")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c b/drivers/soc/tegra/fuse/tegra-apbmisc.c
index 87ae63a7e52d..7aba7c58bad0 100644
--- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
+++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
@@ -117,7 +117,7 @@ bool tegra_is_silicon(void)
 
 u32 tegra_read_straps(void)
 {
-	WARN(!chipid, "Tegra ABP MISC not yet available\n");
+	WARN(!apbmisc_base, "Tegra ABP MISC not yet available\n");
 
 	return strapping;
 }

---
base-commit: 1f5563665c2715e5ab2f64ec3d4b0af60927014f
change-id: 20260604-tegra_warn_fix-f9e8085b4175

Best regards,
-- 
Breno Leitao <leitao@debian.org>

Re: [PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms

[Breno Leitao]

On Thu, Jun 04, 2026 at 03:36:17AM -0700, Breno Leitao wrote:
> My Grace host started to show this warning:
>   WARNING: drivers/soc/tegra/fuse/tegra-apbmisc.c:120 at tegra_read_straps
>    tegra30_fuse_add_randomness
>    tegra30_fuse_init
>    tegra_fuse_probe
> 
> tegra_read_straps() warns when the static "chipid" cache is still zero,
> using it as a proxy for "APBMISC has been initialised". However chipid
> is only ever populated lazily by tegra_read_chipid() when it reads the
> APBMISC register.
> 
> Guard on apbmisc_base instead, which is set unconditionally in
> tegra_init_apbmisc_resources() for all platforms and is already the
> sentinel used by tegra_read_chipid().
> 
> Fixes: c71f213fa5af ("soc/tegra: fuse: Warn if straps are not ready")
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
>  drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> index 87ae63a7e52d..7aba7c58bad0 100644
> --- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
> +++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> @@ -117,7 +117,7 @@ bool tegra_is_silicon(void)
>  
>  u32 tegra_read_straps(void)
>  {
> -	WARN(!chipid, "Tegra ABP MISC not yet available\n");
> +	WARN(!apbmisc_base, "Tegra ABP MISC not yet available\n");

Hello Thierry,

Have you had a chance to look at this one? This is showing up in my
Grace all the time.

Thanks

Re: [PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

On Mon, Jun 15, 2026 at 08:32:25AM -0700, Breno Leitao wrote:
> 
> On Thu, Jun 04, 2026 at 03:36:17AM -0700, Breno Leitao wrote:
> > My Grace host started to show this warning:
> >   WARNING: drivers/soc/tegra/fuse/tegra-apbmisc.c:120 at tegra_read_straps
> >    tegra30_fuse_add_randomness
> >    tegra30_fuse_init
> >    tegra_fuse_probe
> > 
> > tegra_read_straps() warns when the static "chipid" cache is still zero,
> > using it as a proxy for "APBMISC has been initialised". However chipid
> > is only ever populated lazily by tegra_read_chipid() when it reads the
> > APBMISC register.
> > 
> > Guard on apbmisc_base instead, which is set unconditionally in
> > tegra_init_apbmisc_resources() for all platforms and is already the
> > sentinel used by tegra_read_chipid().
> > 
> > Fixes: c71f213fa5af ("soc/tegra: fuse: Warn if straps are not ready")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> >  drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> > index 87ae63a7e52d..7aba7c58bad0 100644
> > --- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
> > +++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> > @@ -117,7 +117,7 @@ bool tegra_is_silicon(void)
> >  
> >  u32 tegra_read_straps(void)
> >  {
> > -	WARN(!chipid, "Tegra ABP MISC not yet available\n");
> > +	WARN(!apbmisc_base, "Tegra ABP MISC not yet available\n");
> 
> Hello Thierry,
> 
> 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")

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?
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.

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

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?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms

[Breno Leitao]

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