Nouveau - Nov 2025 - [PATCH v6 4/5] rust: Move register and bitfield macros out of Nova

On Thu Oct 9, 2025 at 8:16 PM JST, Danilo Krummrich
wrote:
> On Thu Oct 9, 2025 at 8:59 AM CEST, Dirk Behme wrote:
>> Assuming that register.rs is supposed to become the "generic"
way to
>> access hardware registers I started to have a look to it. Some weeks 
>> back testing interrupts I used some quite simple timer with 4 registers
>> [1]. Now, thinking about converting it to register!() I have three 
>> understanding / usage questions:
>>
>> * At the moment register!() is for 32-bit registers, only? So it
can't
>> be used for my example having 8-bit and 16-bit registers as well?
>
> Yes, currently the register!() macro always generates a 32-bit register
type
> (mainly because nova-core did not need anything else). However, this will
of
> course be generalized (which should be pretty straight forward).
>
> Having a brief look at the TMU datasheet it looks like you should be able
to
> treat TSTR and TCR as 32-bit registers without any issues for testing the
> register!() macro today. I.e. you can just define it as:
>
> 	register!(TSTR @ 0x04, "Timer Start Register" {
> 	    2:2    str2 as bool, "Specifies whether TCNT2 is operated or
stopped.";
> 	    1:1    str1 as bool, "Specifies whether TCNT1 is operated or
stopped.";
> 	    0:0    str0 as bool, "Specifies whether TCNT0 is operated or
stopped.";
> 	});
>
> Same for TCR.
Patch 2 of this series actually adds support for 16 and 8 bit register
storage.

On 10/9/25 1:28 PM, Alexandre Courbot wrote:
> On Thu Oct 9, 2025 at 8:16 PM JST, Danilo Krummrich wrote:
>> On Thu Oct 9, 2025 at 8:59 AM CEST, Dirk Behme wrote:
>>> Assuming that register.rs is supposed to become the
"generic" way to
>>> access hardware registers I started to have a look to it. Some
weeks
>>> back testing interrupts I used some quite simple timer with 4
registers
>>> [1]. Now, thinking about converting it to register!() I have three 
>>> understanding / usage questions:
>>>
>>> * At the moment register!() is for 32-bit registers, only? So it
can't
>>> be used for my example having 8-bit and 16-bit registers as well?
>>
>> Yes, currently the register!() macro always generates a 32-bit register
type
>> (mainly because nova-core did not need anything else). However, this
will of
>> course be generalized (which should be pretty straight forward).
>>
>> Having a brief look at the TMU datasheet it looks like you should be
able to
>> treat TSTR and TCR as 32-bit registers without any issues for testing
the
>> register!() macro today. I.e. you can just define it as:
>>
>> 	register!(TSTR @ 0x04, "Timer Start Register" {
>> 	    2:2    str2 as bool, "Specifies whether TCNT2 is operated or
stopped.";
>> 	    1:1    str1 as bool, "Specifies whether TCNT1 is operated or
stopped.";
>> 	    0:0    str0 as bool, "Specifies whether TCNT0 is operated or
stopped.";
>> 	});
>>
>> Same for TCR.
> 
> Patch 2 of this series actually adds support for 16 and 8 bit register
> storage.
Heh! I knew I saw a patch for this already somewhere, seems like I missed the
forest for the trees. :)

On 09.10.25 13:28, Alexandre Courbot wrote:
> On Thu Oct 9, 2025 at 8:16 PM JST, Danilo Krummrich wrote:
>> On Thu Oct 9, 2025 at 8:59 AM CEST, Dirk Behme wrote:
>>> Assuming that register.rs is supposed to become the
"generic" way to
>>> access hardware registers I started to have a look to it. Some
weeks
>>> back testing interrupts I used some quite simple timer with 4
registers
>>> [1]. Now, thinking about converting it to register!() I have three 
>>> understanding / usage questions:
>>>
>>> * At the moment register!() is for 32-bit registers, only? So it
can't
>>> be used for my example having 8-bit and 16-bit registers as well?
>>
>> Yes, currently the register!() macro always generates a 32-bit register
type
>> (mainly because nova-core did not need anything else). However, this
will of
>> course be generalized (which should be pretty straight forward).
>>
>> Having a brief look at the TMU datasheet it looks like you should be
able to
>> treat TSTR and TCR as 32-bit registers without any issues for testing
the
>> register!() macro today. I.e. you can just define it as:
>>
>> 	register!(TSTR @ 0x04, "Timer Start Register" {
>> 	    2:2    str2 as bool, "Specifies whether TCNT2 is operated or
stopped.";
>> 	    1:1    str1 as bool, "Specifies whether TCNT1 is operated or
stopped.";
>> 	    0:0    str0 as bool, "Specifies whether TCNT0 is operated or
stopped.";
>> 	});
>>
>> Same for TCR.
> 
> Patch 2 of this series actually adds support for 16 and 8 bit register
> storage.
Hmm, how to use that with the register!() macro? I mean patch 2 adds
support for different storage widths for *bitfields*. But looking at
patch 4 [2] it looks like *register!()* still uses $name(u32)? With
that it looks like that the register!() macro still just supports 32
bit registers? Or what have I missed?

What I'm looking for is a way to specify if a register is 8, 16 or 32
bit. Using the example from above something like

register!(TSTR<u8> @ ....

Thanks

Dirk

[2]

https://lore.kernel.org/rust-for-linux/20251003154748.1687160-5-joelagnelf at
nvidia.com/

...
+#[macro_export]
 macro_rules! register {
     // Creates a register at a fixed offset of the MMIO space.
     ($name:ident @ $offset:literal $(, $comment:literal)? {
$($fields:tt)* } ) => {
-        bitfield!(pub(crate) struct $name(u32) $(, $comment)? {
$($fields)* } );
+        ::kernel::bitfield!(pub(crate) struct $name(u32) $(,
$comment)? { $($fields)* } );
         register!(@io_fixed $name @ $offset);
     };
...

On Sun Nov 2, 2025 at 3:51 AM JST, Dirk Behme wrote:
> On 09.10.25 13:28, Alexandre Courbot wrote:
>> On Thu Oct 9, 2025 at 8:16 PM JST, Danilo Krummrich wrote:
>>> On Thu Oct 9, 2025 at 8:59 AM CEST, Dirk Behme wrote:
>>>> Assuming that register.rs is supposed to become the
"generic" way to
>>>> access hardware registers I started to have a look to it. Some
weeks
>>>> back testing interrupts I used some quite simple timer with 4
registers
>>>> [1]. Now, thinking about converting it to register!() I have
three
>>>> understanding / usage questions:
>>>>
>>>> * At the moment register!() is for 32-bit registers, only? So
it can't
>>>> be used for my example having 8-bit and 16-bit registers as
well?
>>>
>>> Yes, currently the register!() macro always generates a 32-bit
register type
>>> (mainly because nova-core did not need anything else). However,
this will of
>>> course be generalized (which should be pretty straight forward).
>>>
>>> Having a brief look at the TMU datasheet it looks like you should
be able to
>>> treat TSTR and TCR as 32-bit registers without any issues for
testing the
>>> register!() macro today. I.e. you can just define it as:
>>>
>>> 	register!(TSTR @ 0x04, "Timer Start Register" {
>>> 	    2:2    str2 as bool, "Specifies whether TCNT2 is operated
or stopped.";
>>> 	    1:1    str1 as bool, "Specifies whether TCNT1 is operated
or stopped.";
>>> 	    0:0    str0 as bool, "Specifies whether TCNT0 is operated
or stopped.";
>>> 	});
>>>
>>> Same for TCR.
>> 
>> Patch 2 of this series actually adds support for 16 and 8 bit register
>> storage.
>
> Hmm, how to use that with the register!() macro? I mean patch 2 adds
> support for different storage widths for *bitfields*. But looking at
> patch 4 [2] it looks like *register!()* still uses $name(u32)? With
> that it looks like that the register!() macro still just supports 32
> bit registers? Or what have I missed?
>
> What I'm looking for is a way to specify if a register is 8, 16 or 32
> bit. Using the example from above something like
>
> register!(TSTR<u8> @ ....
Errr indeed, you are correct. The `register` macro's syntax has not been
updated to take advantage of `bitfield`'s storage types, and `u32` is
still hardcoded as of this series.

This looks like an oversight - a register is basically a bitfield with
some I/O, so making it support storage types should be trivial. I guess
this hasn't been done yet because Nova is the only user so far, and we
don't need/want to explicitly specify a type for each register since
they are invariably `u32`.

But it wouldn't look good to change the syntax of `register` after
moving it out, so I agree this should take place before the move. The
same applies to the visiblity feature.

One way to avoid a update all the declarations so far would be to give
Nova its own `register` macro that invokes the one in `kernel` with
the relevant parameters hardcoded.