Re: [PATCH 1/2] soc/tegra: fuse: Return -ENODEV for unsupported legacy SoCs

--vh6hi6mdbexesfye
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 1/2] soc/tegra: fuse: Return -ENODEV for unsupported
 legacy SoCs
MIME-Version: 1.0

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.
>=20
> In that case fuse->soc remains NULL, but initialization continues and
> later calls fuse->soc->init(fuse), which results in a NULL pointer
> dereference.
>=20
> Return -ENODEV from the default case to stop initialization immediately
> when the legacy fallback detects an unsupported SoC.
>=20
> Fixes: 7e939de1b2bb ("soc/tegra: fuse: Unify Tegra20 and Tegra30 drivers")
> Signed-off-by: Jinhui Guo <[email protected]>
> ---
>  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

--vh6hi6mdbexesfye
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmpy6NAACgkQ3SOs138+
s6EY0hAAsk8MjtBlce3zfcsweOa5LAYZsMHbIKzJZ1BXFjirCsVQLst8PLGaKw+o
jus0+T2+ZZcij6bAijoc7BvAarXG3GnFkH8c/zbi4xQnS145Xg5RAilj6NzFmNq8
Zvf4WMRT19uV49s6Jp7OwfcnMogr43JVNELlv8o8Fo22dbajEmin1Yyk9dVgB6B9
rhx+rM54IJLlAtPfr5wOUfV9kaiB6ZEVhlxvewtAx/Wb0ohZ+dno1liSRmJokdqL
+volFXqNPpobuYqnadkqcX+T0bqHnPGQKes6LkU55yoxEiPzIP7V6S1P6b77ymbF
YQSN5huflhiREThjaGwOihIFUl/gAtgGlZClzk9u0cCKc9brZ/noCgl8BVozJllk
pvVBAMK8d7k1RwRH3qTq6dYuT7czVK3OGPBudSI9BkYAVWaiO7bnpaXYIszYqe9d
DTPZeIUae5g8rxR/yfivmmvzjk+PaLojFRYKyptHEDvhsBepD9lOyfR/a9fWm0tD
DieioLyuojFhHlBHILWpXAJdyAV6bvCgMa4HqCo8cBrKtO36H0d2QHIeIbTYU7mu
Z3wJ4lJomxhSqFzMdG/2nG8r5PMQ62Q/2f87iikdYbRwSNSJhmII2WGUVcIYbAuY
fyH4cFai24in/x2DLvgPyQ179eHE0PAwg97R1lupFDwjIM9fKiA=
=10WP
-----END PGP SIGNATURE-----

--vh6hi6mdbexesfye--