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 <[email protected]> > --- > 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 <[email protected]> thanks, -- John Hubbard
