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

[John Hubbard <jhubbard@nvidia.com>]

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