This is the continuation of the `bitfield!` macro which started
alongside the `register!` one before being temporarily integrated into
it [1].

There were still ongoing discussions in [1], notably about improving the
ergonomics of setting bitfield values. This revision doesn't try to
address them yet (although the `with_const` setters partially solve the
issue); it just extracts the `bitfield!` macro and makes it available,
for the following reasons:

- To get the ball rolling again after several months of hiatus,
- Because it is already useful as-is, and ergonomics will be improved
  with macros built on top of the existing code,
- To allow dependencies over this series, notably the Nova MM series.

Thus, the discussions about ergonomics could take place as part of this
series, or as a follow-up - after all, bitfields are just registers
without I/O, so the present proposal does not introduce anything that is
not already in the kernel.

[1] https://lore.kernel.org/all/20260120-register-v1-0-723a1743b557@nvidia.com/

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Alexandre Courbot (2):
      rust: extract `bitfield!` macro from `register!`
      gpu: nova-core: switch to kernel bitfield macro

Joel Fernandes (1):
      rust: bitfield: Add KUNIT tests for bitfield

 MAINTAINERS                        |   8 +
 drivers/gpu/nova-core/bitfield.rs  | 329 ---------------
 drivers/gpu/nova-core/gsp/fw.rs    |  15 +-
 drivers/gpu/nova-core/nova_core.rs |   3 -
 rust/kernel/bitfield.rs            | 809 +++++++++++++++++++++++++++++++++++++
 rust/kernel/io/register.rs         | 246 +----------
 rust/kernel/lib.rs                 |   1 +
 7 files changed, 828 insertions(+), 583 deletions(-)
---
base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd
change-id: 20260408-bitfield-6e18254f4fdc

Best regards,
--  
Alexandre Courbot <acourbot@nvidia.com>

On 4/9/26 7:58 AM, Alexandre Courbot wrote:
> This is the continuation of the `bitfield!` macro which started
> alongside the `register!` one before being temporarily integrated into
> it [1].
> 
> There were still ongoing discussions in [1], notably about improving the
> ergonomics of setting bitfield values. This revision doesn't try to
> address them yet (although the `with_const` setters partially solve the
> issue); it just extracts the `bitfield!` macro and makes it available,
> for the following reasons:
> 
> - To get the ball rolling again after several months of hiatus,
> - Because it is already useful as-is, and ergonomics will be improved

Yes, and I'm worried now that we can't write things such as Joel's page
tables without it.

Can we please put this into your drm-rust-next-staging ASAP? I don't
think we have any comments that would really need to hold that up.


thanks,
-- 
John Hubbard

On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
> Can we please put this into your drm-rust-next-staging ASAP? I don't
> think we have any comments that would really need to hold that up.

I would like to see the first patch being split up and we also need to agree the
merge strategy for this series and obtain the corresponding ACKs first.

That said, I'm not a huge fan of the drm-rust-next-staging thing. It started out
as part of Alex' (private) process of staging patches he's about to pick up
(which is fine of course).

But now it seems to develop into some semi-official "shadow infrastructure" for
when the drm-rust tree is closed after -rc6 and during the merge window, and
it's not part of the official drm-rust workflow and other maintainers don't have
oversight of it.

So, in order to not motivate workarounds, starting from the next cycle, the
drm-rust-next branch will be open for new features at all times.

Consequently, all patches applied to drm-rust-next after -rc6 do not target the
upcoming merge window, but the next one.

Fixes for code that is within drm-rust-next and was merged before -rc6 have to
go into drm-rust-next-fixes.

drm-rust-fixes will continue to be the target for fixes for the current -rc.

I will update all corresponding documentation in the next days and send another
announcement mail, so it is not only this one buried in a thread where no one
expects it. :)

- Danilo

On Fri, Apr 17, 2026 at 12:19 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> But now it seems to develop into some semi-official "shadow infrastructure" for
> when the drm-rust tree is closed after -rc6 and during the merge window, and
> it's not part of the official drm-rust workflow and other maintainers don't have
> oversight of it.
>
> So, in order to not motivate workarounds, starting from the next cycle, the
> drm-rust-next branch will be open for new features at all times.
>
> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
> upcoming merge window, but the next one.

I think that for branches going into linux-next, in general, new
material is not meant to be added until the merge window closes, e.g.
from last -next:

    The merge window is open, so please to not addd any v7.1 material
    to your linux-next included branches until after the merge window closes.

Some things do target future merge windows (e.g. Rust itself was such
a case for a long time), so it may be fine when adding it before the
merge window opens, but I think the idea is mostly to avoid too much
movement during the merge window to avoid interfering with other
maintainers finishing their trees for Linus etc.

But not sure how flexible this is -- Cc'ing Mark.

Cheers,
Miguel

On Fri Apr 17, 2026 at 7:55 AM CEST, Miguel Ojeda wrote:
> I think that for branches going into linux-next, in general, new
> material is not meant to be added until the merge window closes, e.g.
> from last -next:
>
>     The merge window is open, so please to not addd any v7.1 material
>     to your linux-next included branches until after the merge window closes.
>
> Some things do target future merge windows (e.g. Rust itself was such
> a case for a long time), so it may be fine when adding it before the
> merge window opens, but I think the idea is mostly to avoid too much
> movement during the merge window to avoid interfering with other
> maintainers finishing their trees for Linus etc.
>
> But not sure how flexible this is -- Cc'ing Mark.

This all builds on the assumption that we don't have a process in place that
covers this.

However, all major DRM trees run the above process and handle linux-next in the
following way.

  * -next
        Features; open at all times.

  * -next-fixes
        Fixes for features in -next that have been included before -rc6; active
        between -rc6 and the next -rc1.

  * -fixes
        Fixes targeting the current -rc cycle.

These are mapped to two additional branches that linux-next pulls from:

  * for-linux-next
        Normally points to -next. Between -rc6 and -rc1 it switches to
        -next-fixes instead.

  * for-linux-next-fixes
        Always points to -fixes.

The same thing is going to happen for drm-rust tree, once everything is set up.

- Danilo

On Fri, Apr 17, 2026 at 2:00 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> This all builds on the assumption that we don't have a process in place that
> covers this.

It builds on what happens today. From what I saw, Mark merges
`drm-rust-next`, which is why I mentioned it, i.e. to help prevent
something unexpected around `linux-next`.

If the branches going into `linux-next` change, then great!

Cheers,
Miguel

On Fri Apr 17, 2026 at 2:21 PM CEST, Miguel Ojeda wrote:
> On Fri, Apr 17, 2026 at 2:00 PM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> This all builds on the assumption that we don't have a process in place that
>> covers this.
>
> It builds on what happens today. From what I saw, Mark merges
> `drm-rust-next`, which is why I mentioned it, i.e. to help prevent
> something unexpected around `linux-next`.

We're not running the new process yet, so the current state isn't relevant. The
for-linux-next handling will be in place before anything changes for Mark.

On Fri, Apr 17, 2026 at 07:55:57AM +0200, Miguel Ojeda wrote:
> On Fri, Apr 17, 2026 at 12:19 AM Danilo Krummrich <dakr@kernel.org> wrote:

> > So, in order to not motivate workarounds, starting from the next cycle, the
> > drm-rust-next branch will be open for new features at all times.

> > Consequently, all patches applied to drm-rust-next after -rc6 do not target the
> > upcoming merge window, but the next one.

> I think that for branches going into linux-next, in general, new
> material is not meant to be added until the merge window closes, e.g.
> from last -next:

>     The merge window is open, so please to not addd any v7.1 material
>     to your linux-next included branches until after the merge window closes.

> Some things do target future merge windows (e.g. Rust itself was such
> a case for a long time), so it may be fine when adding it before the
> merge window opens, but I think the idea is mostly to avoid too much
> movement during the merge window to avoid interfering with other
> maintainers finishing their trees for Linus etc.

> But not sure how flexible this is -- Cc'ing Mark.

Yes, the idea is that at the end of the merge window -next should only
have a few fixes in it since everything should've been sent to Linus.
This also applies to things being added after you've sent your pulls to
the DRM core maintainers, if something isn't going to go in during the
merge window you shouldn't be adding it to -next.  

For the most part nobody's actually checking that other than the reports
I send to Linus highlighting which trees have the most commits in -next
so if you're not disruptive the chances are nobody will notice but you
shouldn't do it.  As Miguel says it's trying to avoid causing issues for
other people, plus the general concept of -next is that it's covering
what's currently scheduled to go into Linus' tree.

Of course, nothing stops you maintaining a branch which isn't in -next
and is open all the time and that won't have any wider impact.

On Fri Apr 17, 2026 at 12:59 PM CEST, Mark Brown wrote:
> Of course, nothing stops you maintaining a branch which isn't in -next
> and is open all the time and that won't have any wider impact.

This is exactly what's going to happen, please see [1].

Thanks,
Danilo

[1] https://lore.kernel.org/lkml/DHVEWDBHYKQF.XBXZ704CMXCF@kernel.org/

On Fri Apr 17, 2026 at 7:18 AM JST, Danilo Krummrich wrote:
> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>> think we have any comments that would really need to hold that up.
>
> I would like to see the first patch being split up and we also need to agree the
> merge strategy for this series and obtain the corresponding ACKs first.
>
> That said, I'm not a huge fan of the drm-rust-next-staging thing. It started out
> as part of Alex' (private) process of staging patches he's about to pick up
> (which is fine of course).

Yeah, if we added this patch it would then become a mix of "things to
push when drm-rust-next" reopens, and "things NVIDIA depends on but are
not ready yet". For the record I was a bit slow to reply but would have
suggested carrying this patch outside of `drm-rust-next-staging` to not
mix things up.

>
> But now it seems to develop into some semi-official "shadow infrastructure" for
> when the drm-rust tree is closed after -rc6 and during the merge window, and
> it's not part of the official drm-rust workflow and other maintainers don't have
> oversight of it.
>
> So, in order to not motivate workarounds, starting from the next cycle, the
> drm-rust-next branch will be open for new features at all times.
>
> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
> upcoming merge window, but the next one.

If that doesn't add any burden to you and Alice, then I think that's a
definitely an improvement to our process.

>
> Fixes for code that is within drm-rust-next and was merged before -rc6 have to
> go into drm-rust-next-fixes.
>
> drm-rust-fixes will continue to be the target for fixes for the current -rc.
>
> I will update all corresponding documentation in the next days and send another
> announcement mail, so it is not only this one buried in a thread where no one
> expects it. :)

Appreciate it! Thanks for doing this.

On Fri Apr 17, 2026 at 10:33 AM JST, Alexandre Courbot wrote:
> On Fri Apr 17, 2026 at 7:18 AM JST, Danilo Krummrich wrote:
>> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>>> think we have any comments that would really need to hold that up.
>>
>> I would like to see the first patch being split up and we also need to agree the
>> merge strategy for this series and obtain the corresponding ACKs first.
>>
>> That said, I'm not a huge fan of the drm-rust-next-staging thing. It started out
>> as part of Alex' (private) process of staging patches he's about to pick up
>> (which is fine of course).
>
> Yeah, if we added this patch it would then become a mix of "things to
> push when drm-rust-next" reopens, and "things NVIDIA depends on but are
> not ready yet". For the record I was a bit slow to reply but would have
> suggested carrying this patch outside of `drm-rust-next-staging` to not
> mix things up.
>
>>
>> But now it seems to develop into some semi-official "shadow infrastructure" for
>> when the drm-rust tree is closed after -rc6 and during the merge window, and
>> it's not part of the official drm-rust workflow and other maintainers don't have
>> oversight of it.
>>
>> So, in order to not motivate workarounds, starting from the next cycle, the
>> drm-rust-next branch will be open for new features at all times.
>>
>> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
>> upcoming merge window, but the next one.
>
> If that doesn't add any burden to you and Alice, then I think that's a
> definitely an improvement to our process.

Actually thinking more about this, this might not be the improvement I
expected at first.

Take for instance the current time of the merge window: both `rust-next`
and `drm-rust-next` have been merged into `master`, which provides us an
ideal base for sending patches that will target `-rc1`.

But if we keep submitting to the pre-merge `drm-rust-next`, then we are
in a situation where the extra patches sent to `drm-rust-next` need to
be rebased when `-rc1` is released, with a clear potential for
conflicts.

So at the end of the day, it would still be cleaner to use `master` in
prevision of the `-rc1` tagging and we would be in more or less the same
situation as today. `drm-rust-next-staging` is currently based on
`master`.

I guess the problem is that my internal process has leaked a bit, when
it is really intended to be a temporary convenience (both for me and for
NVIDIA contributors) and something drm-rust maintainers can completely
ignore.

On 4/16/26 8:11 PM, Alexandre Courbot wrote:
> On Fri Apr 17, 2026 at 10:33 AM JST, Alexandre Courbot wrote:
>> On Fri Apr 17, 2026 at 7:18 AM JST, Danilo Krummrich wrote:
>>> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>>>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>>>> think we have any comments that would really need to hold that up.
...
>>> But now it seems to develop into some semi-official "shadow infrastructure" for
>>> when the drm-rust tree is closed after -rc6 and during the merge window, and
>>> it's not part of the official drm-rust workflow and other maintainers don't have
>>> oversight of it.
>>>
>>> So, in order to not motivate workarounds, starting from the next cycle, the
>>> drm-rust-next branch will be open for new features at all times.
>>>
>>> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
>>> upcoming merge window, but the next one.
>>
>> If that doesn't add any burden to you and Alice, then I think that's a
>> definitely an improvement to our process.
> 
> Actually thinking more about this, this might not be the improvement I
> expected at first.
> 
> Take for instance the current time of the merge window: both `rust-next`
> and `drm-rust-next` have been merged into `master`, which provides us an
> ideal base for sending patches that will target `-rc1`.
> 
> But if we keep submitting to the pre-merge `drm-rust-next`, then we are
> in a situation where the extra patches sent to `drm-rust-next` need to
> be rebased when `-rc1` is released, with a clear potential for
> conflicts.

Yes, some conflicts, but probably not too bad, due to the much
newer base, right?

> 
> So at the end of the day, it would still be cleaner to use `master` in
> prevision of the `-rc1` tagging and we would be in more or less the same
> situation as today. `drm-rust-next-staging` is currently based on
> `master`.
> 
> I guess the problem is that my internal process has leaked a bit, when
> it is really intended to be a temporary convenience (both for me and for
> NVIDIA contributors) and something drm-rust maintainers can completely
> ignore.

The only reason that it leaked is because there was an underlying unmet
need, to begin with, which is: how to continue developing on some
"appropriate" branch during two weeks (20% of the year) when our main
branch is locked down and stale?

There is a real need to do something.


thanks,
-- 
John Hubbard

On Fri Apr 17, 2026 at 12:19 PM JST, John Hubbard wrote:
> On 4/16/26 8:11 PM, Alexandre Courbot wrote:
>> On Fri Apr 17, 2026 at 10:33 AM JST, Alexandre Courbot wrote:
>>> On Fri Apr 17, 2026 at 7:18 AM JST, Danilo Krummrich wrote:
>>>> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>>>>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>>>>> think we have any comments that would really need to hold that up.
> ...
>>>> But now it seems to develop into some semi-official "shadow infrastructure" for
>>>> when the drm-rust tree is closed after -rc6 and during the merge window, and
>>>> it's not part of the official drm-rust workflow and other maintainers don't have
>>>> oversight of it.
>>>>
>>>> So, in order to not motivate workarounds, starting from the next cycle, the
>>>> drm-rust-next branch will be open for new features at all times.
>>>>
>>>> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
>>>> upcoming merge window, but the next one.
>>>
>>> If that doesn't add any burden to you and Alice, then I think that's a
>>> definitely an improvement to our process.
>> 
>> Actually thinking more about this, this might not be the improvement I
>> expected at first.
>> 
>> Take for instance the current time of the merge window: both `rust-next`
>> and `drm-rust-next` have been merged into `master`, which provides us an
>> ideal base for sending patches that will target `-rc1`.
>> 
>> But if we keep submitting to the pre-merge `drm-rust-next`, then we are
>> in a situation where the extra patches sent to `drm-rust-next` need to
>> be rebased when `-rc1` is released, with a clear potential for
>> conflicts.
>
> Yes, some conflicts, but probably not too bad, due to the much
> newer base, right?

Most of the time, hopefully. But that's still labor shifted from us (as
I would address the conflicts before merging the patches) to the
drm-rust maintainers.

>
>> 
>> So at the end of the day, it would still be cleaner to use `master` in
>> prevision of the `-rc1` tagging and we would be in more or less the same
>> situation as today. `drm-rust-next-staging` is currently based on
>> `master`.
>> 
>> I guess the problem is that my internal process has leaked a bit, when
>> it is really intended to be a temporary convenience (both for me and for
>> NVIDIA contributors) and something drm-rust maintainers can completely
>> ignore.
>
> The only reason that it leaked is because there was an underlying unmet
> need, to begin with, which is: how to continue developing on some
> "appropriate" branch during two weeks (20% of the year) when our main
> branch is locked down and stale?

It's actually 4 weeks (from -rc6 to release, plus 2 weeks until -rc1).

I agree it would be nice to improve the situation - I'm just not sure
that keeping drm-rust-next open is the optimal solution here.

On 4/16/26 8:57 PM, Alexandre Courbot wrote:
...
>> Yes, some conflicts, but probably not too bad, due to the much
>> newer base, right?
> 
> Most of the time, hopefully. But that's still labor shifted from us (as
> I would address the conflicts before merging the patches) to the
> drm-rust maintainers.

This point would carry some real weight, were it not for the fact that
one of the drm-rust maintainers is the one who suggested this approach!

Please let's take "yes" for an answer here.

...
> It's actually 4 weeks (from -rc6 to release, plus 2 weeks until -rc1).

I knew it felt longer than 20%. So yes, 40% of the year. This is a real
gap.

> 
> I agree it would be nice to improve the situation - I'm just not sure
> that keeping drm-rust-next open is the optimal solution here.

Me neither, but I'm *very* convinced that it is a solid improvement over
what we have been doing. I really don't see the case against doing this.


thanks,
-- 
John Hubbard

On 4/16/26 3:18 PM, Danilo Krummrich wrote:
> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>> think we have any comments that would really need to hold that up.
> 
> I would like to see the first patch being split up and we also need to agree the
> merge strategy for this series and obtain the corresponding ACKs first.
> 
> That said, I'm not a huge fan of the drm-rust-next-staging thing. It started out
> as part of Alex' (private) process of staging patches he's about to pick up
> (which is fine of course).
> 
> But now it seems to develop into some semi-official "shadow infrastructure" for
> when the drm-rust tree is closed after -rc6 and during the merge window, and
> it's not part of the official drm-rust workflow and other maintainers don't have
> oversight of it.

Yes, a patchset vaccuum existed. :)

> 
> So, in order to not motivate workarounds, starting from the next cycle, the
> drm-rust-next branch will be open for new features at all times.
> 
> Consequently, all patches applied to drm-rust-next after -rc6 do not target the
> upcoming merge window, but the next one.
> 
> Fixes for code that is within drm-rust-next and was merged before -rc6 have to
> go into drm-rust-next-fixes.
> 
> drm-rust-fixes will continue to be the target for fixes for the current -rc.
> 

Perfect, that's what we were instintively trying to replicate, after all.

> I will update all corresponding documentation in the next days and send another
> announcement mail, so it is not only this one buried in a thread where no one
> expects it. :)
> 
> - Danilo

thanks,
-- 
John Hubbard

On Thu Apr 16, 2026 at 8:22 AM JST, John Hubbard wrote:
> On 4/9/26 7:58 AM, Alexandre Courbot wrote:
>> This is the continuation of the `bitfield!` macro which started
>> alongside the `register!` one before being temporarily integrated into
>> it [1].
>> 
>> There were still ongoing discussions in [1], notably about improving the
>> ergonomics of setting bitfield values. This revision doesn't try to
>> address them yet (although the `with_const` setters partially solve the
>> issue); it just extracts the `bitfield!` macro and makes it available,
>> for the following reasons:
>> 
>> - To get the ball rolling again after several months of hiatus,
>> - Because it is already useful as-is, and ergonomics will be improved
>
> Yes, and I'm worried now that we can't write things such as Joel's page
> tables without it.
>
> Can we please put this into your drm-rust-next-staging ASAP? I don't
> think we have any comments that would really need to hold that up.
>
>
> thanks,

Yes this seems fine to me as well. I'm personally fine with improving
the build errors in a follow-up.