Re: [PATCH] gpu: nova-core: require little endian

John Hubbard
2026-04-06T19:37:58Z

On 4/5/26 11:52 PM, Eliot Courtney wrote:
> The driver already assumes little endian in a lot of locations. For
> example, all the code that reads RPCs out of the command queue just
> directly interprets the bytes.

Yes, and that even understates the scope. The FromBytes-based parsing
of repr(C) structs happens in firmware loading, VBIOS parsing, and GSP
shared memory, not just command queue RPCs.

>
> Make this explicit in Kconfig.
>
> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
> ---
> The current code assumes little endian in a bunch of places. I think we
> should either explicitly decide to be generic on endianness or explicitly
> decide not to - having some handling sprinkled around in various
> locations seems confusing to me.
>
> I believe that currently e.g. `RUST` transitively depends on
> !CPU_BIG_ENDIAN, so this is more about making the decision explicit for
> nova-core rather than fixing any kind of hole.

That's true today in practice, but config RUST does not directly depend
on !CPU_BIG_ENDIAN. The exclusion happens per-arch: ARM and ARM64 gate
HAVE_RUST on CPU_LITTLE_ENDIAN, and x86_64 and LoongArch are inherently
LE.

RISC-V is more exciting because it selects HAVE_RUST without an explicit
endianness check.

So putting the dependency in nova-core directly is a good move, not just
for documentation but as a real guard.

> ---
> drivers/gpu/nova-core/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
> index a4f2380654e2..d8456f8eaa05 100644
> --- a/drivers/gpu/nova-core/Kconfig
> +++ b/drivers/gpu/nova-core/Kconfig
> @@ -3,6 +3,7 @@ config NOVA_CORE
> depends on 64BIT
> depends on PCI
> depends on RUST
> + depends on !CPU_BIG_ENDIAN
> select AUXILIARY_BUS
> select RUST_FW_LOADER_ABSTRACTIONS
> default n
>
> ---
> base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd
> change-id: 20260406-fix-kconfig-3a059f622697
>

Reviewed-by: John Hubbard <jhubbard@nvidia.com>

thanks,
--
John Hubbard