On Tue, Aug 04, 2026 at 08:19:09PM +0800, Jinhui Guo wrote:
> When booting without a FUSE device tree node, tegra_init_fuse() falls
> back to legacy SoC detection on 32-bit ARM systems. If the detected chip
> ID does not match any supported SoC, the default case only prints a
> warning and breaks out of the switch statement.
> 
> In that case fuse->soc remains NULL, but initialization continues and
> later calls fuse->soc->init(fuse), which results in a NULL pointer
> dereference.
> 
> Return -ENODEV from the default case to stop initialization immediately
> when the legacy fallback detects an unsupported SoC.
> 
> Fixes: 7e939de1b2bb ("soc/tegra: fuse: Unify Tegra20 and Tegra30 drivers")
> Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com>
> ---
>  drivers/soc/tegra/fuse/fuse-tegra.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

The likelihood of this happening is pretty much zero. The only way that
you could potentially trigger it is by intentionally booting the system
with an entirely wrong DTB. Like if you booted a Tegra DTB on an Exynos
system or something. In that case it's likely that things will go side-
ways much earlier than this and you kind of deserve the crash from the
fuse->soc being NULL.

As such this is kind of a feature that prevents the boot from continuing
even though it doesn't stand a chance.

Then again, I suspect some AI or static analyzer flagged that we might
run into a NULL dereference, so if I don't take this, someone else is
just going to send a similar patch at some point.

Maybe a good compromise would be to turn the pr_warn() into a BUG() to
keep the system from booting and make it obvious to analyzers that we're
not intending to proceed in this case.

Thierry