Nouveau - Oct 2025 - [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/

On Wed Oct 8, 2025 at 4:28 PM CEST, Yury Norov wrote:
> On Wed, Oct 08, 2025 at 12:08:59AM +0200, Danilo Krummrich wrote:
>
>> Regarding the bitfields for page table management: Are we
>> sure that we can use raw bitfields for this?
>
> As per my current understanding we can't. Bitfields are not suitable
for
> direct I/O and considered as a data storage. In the current scheme:
>
>         regs::NV_PFALCON_FALCON_DMATRFBASE::default()
>             .set_base((dma_start >> 8) as u32)
>             .write(bar, &E::ID);
>
> we account for endianess in the .write() method, which would be a part
> of register API, not bitfields.
I know, I proposed this register API design about a year ago, and Alex came up
with an awesome implementation for it. :)

And yes, your understanding is correct, the idea is that the I/O backend that
knows about the underlying bus, etc. takes care of the endianess.

However, we might still be able to use bitfields natively for page table
management structures: In [1] I asked for the NV_PMC_BOOT_1 register, which
might provide some endianess switch to ensure that we always match CPU
endianess.
> FYI: ARM64 is in process of dropping BE, and Linus announced the end
> of BE support for RISC-V:
Yeah, I'm aware of the thread. Also note that for RISC-V it was also
clarified
that if it turns out that BE for RISC-V becomes relevant it would also find its
way into the kernel. If that's likely is of course a different question.

However, there are still architectures such as s390x that could be supported.

So, long story short, my question from above is more meant to challenge if we
can really always guarantee that CPU and GPU endianess match for nova-core.

[1] https://lore.kernel.org/lkml/DDCV84IJHUML.126CB1CT0XMX5 at kernel.org/