[PATCH v4 0/7] rust: add `bitfield!` macro

Alexandre Courbot posted 7 patches 1 week, 5 days ago
There is a newer version of this series
MAINTAINERS                        |   7 +
drivers/gpu/nova-core/bitfield.rs  | 329 --------------
drivers/gpu/nova-core/gsp/fw.rs    |  11 +-
drivers/gpu/nova-core/nova_core.rs |   3 -
rust/kernel/Kconfig.test           |  10 +
rust/kernel/bitfield.rs            | 863 +++++++++++++++++++++++++++++++++++++
rust/kernel/io/register.rs         | 246 +----------
rust/kernel/lib.rs                 |   1 +
8 files changed, 889 insertions(+), 581 deletions(-)
[PATCH v4 0/7] rust: add `bitfield!` macro
Posted by Alexandre Courbot 1 week, 5 days ago
This is the continuation of the `bitfield!` macro which started
alongside the `register!` one before being temporarily integrated into
it [1].

Thanks for all the feedback on v2; I believe this version addresses all
of it, modulo Eliot's suggestion for more explicit range error messages.
Since this is not fundamentally broken, I'd like to address this in a
follow-up change to keep the series focused on the macro extraction from
`register!`.

This version is based on `rust-next`, with [2] applied. If review proves
satisfying, the merge path with the least friction seems to be patches
1-3 into the rust tree this cycle, followed by patch 4 through the I/O
tree, and patches 5-6 via the DRM tree during the next cycle. Patch 7
can be merged after [2].

A tree with this branch and its dependencies is available at [3].

[1] https://lore.kernel.org/all/20260120-register-v1-0-723a1743b557@nvidia.com/
[2] https://lore.kernel.org/all/20260417031531.315281-1-ynorov@nvidia.com/
[3] https://github.com/Gnurou/linux/tree/b4/bitfield

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Changes in v4:
- Inline private bitfield accessor methods.
- Fully qualify types in `bitfield!` macro.
- Rename `RUST_KERNEL_BITFIELD_KUNIT_TEST` to `RUST_BITFIELD_KUNIT_TEST`.
- Link to v3: https://patch.msgid.link/20260501-bitfield-v3-0-aa1076c3337d@nvidia.com

Changes in v3:
- Split patch 1 into the addition of the `bitfield!` macro and its use
  in the `io` module.
- Mention reserved field names in `bitfield!`'s doccomment.
- Properly order fields in the KUnit test.
- Add a Kconfig option for building the KUnit tests.
- Document behavior on non-covered bits.
- Document support for signed fields and storage types (TL;DR: not
  supported).
- Move `nova-core`'s `bitfield` module deletion into its own patch.
- Link to v2: https://patch.msgid.link/20260409-bitfield-v2-0-23ac400071cb@nvidia.com

---
Alexandre Courbot (6):
      rust: extract `bitfield!` macro from `register!`
      rust: bitfield: inline private accessors
      rust: bitfield: fully qualify types in macro
      rust: io: use the `bitfield!` macro in `register!`
      gpu: nova-core: switch to kernel bitfield macro
      gpu: nova-core: remove the driver-local `bitfield!` macro

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

 MAINTAINERS                        |   7 +
 drivers/gpu/nova-core/bitfield.rs  | 329 --------------
 drivers/gpu/nova-core/gsp/fw.rs    |  11 +-
 drivers/gpu/nova-core/nova_core.rs |   3 -
 rust/kernel/Kconfig.test           |  10 +
 rust/kernel/bitfield.rs            | 863 +++++++++++++++++++++++++++++++++++++
 rust/kernel/io/register.rs         | 246 +----------
 rust/kernel/lib.rs                 |   1 +
 8 files changed, 889 insertions(+), 581 deletions(-)
---
base-commit: 72d33b8bfeacbfdccf2cda4650e8e002def036f8
change-id: 20260408-bitfield-6e18254f4fdc
prerequisite-message-id: 20260417031531.315281-1-ynorov@nvidia.com
prerequisite-patch-id: 403e34bb92b42d3f31ed972e11896d18902585e3
prerequisite-patch-id: 42ae775aa6762a9e28ff31c5f69a0b65a7b40dcc
prerequisite-patch-id: 19b3e535962348f7627ede57ea829b34abda08c7

Best regards,
--  
Alexandre Courbot <acourbot@nvidia.com>
Re: [PATCH v4 0/7] rust: add `bitfield!` macro
Posted by Danilo Krummrich 2 days, 7 hours ago
On Wed May 27, 2026 at 2:51 PM CEST, Alexandre Courbot wrote:
> This version is based on `rust-next`, with [2] applied. If review proves
> satisfying, the merge path with the least friction seems to be patches
> 1-3 into the rust tree this cycle, followed by patch 4 through the I/O
> tree, and patches 5-6 via the DRM tree during the next cycle. Patch 7
> can be merged after [2].

Would be great if all of this can go through rust-next this cycle.

Acked-by: Danilo Krummrich <dakr@kernel.org>