Hello!

These patches extract and enhance the bitfield support in the register macro in
nova to define Rust structures with bitfields. It then moves out the bitfield
support into the kenrel crate and further enhances it. This is extremely useful
as it allows clean Rust structure definitions without requiring explicit masks
and shifts.

See [1] example code using it.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/patch/?id=76797b31facae8f1a1be139412c78568df1da9f3

v4 of the patches are at:
https://lore.kernel.org/all/20250920182232.2095101-1-joelagnelf@nvidia.com/

v3 of the patches are at:
https://lore.kernel.org/all/20250909212039.227221-1-joelagnelf@nvidia.com/

v2 of the patches are at:
https://lore.kernel.org/all/20250903215428.1296517-1-joelagnelf@nvidia.com/

v1 of the patches are at:
https://lore.kernel.org/all/20250824135954.2243774-1-joelagnelf@nvidia.com/

v4->v5:
* Added 2 hardening patches to catch the misuse of the API.
* Limited access to the inner value of the struct.
* Fixed kunit tests
* Addressed feedback from lots of folks (Miguel, Alexandre, Yury, Danilo).
* Added Alex tags to most patches.

v3->v4:
* Rebased on -next.
* Added more test cases.
* Added support for fields larger than the struct
  (ex, using 'as u32' for a u8 struct.)

v2->v3:
* Renamed bitstruct to bitfield.
* Various suggestions to improve code (Alex, Yury, Miguel).
* Added reviewed-by tags from Elle Rhumsaa.
* Added KUNIT tests including tests for overlap.
* Added F: maintainers file entry for new files under BITOPS.

v1->v2:
* Use build_assert in bitstruct
* Split move and enhance patches for easier review
* Move out of Nova into kernel crate for other drivers like Tyr which will use.
* Miscellaneous cosmetic improvements.

Joel Fernandes (9):
  nova-core: bitfield: Move bitfield-specific code from register! into
    new macro
  nova-core: bitfield: Add support for different storage widths
  nova-core: bitfield: Add support for custom visiblity
  rust: Move register and bitfield macros out of Nova
  rust: bitfield: Add a new() constructor and raw() accessor
  rust: bitfield: Add KUNIT tests for bitfield
  rust: bitfield: Use 'as' operator for setter type conversion
  rust: bitfield: Add hardening for out of bounds access
  rust: bitfield: Add hardening for undefined bits

 MAINTAINERS                                   |   7 +
 drivers/gpu/nova-core/falcon.rs               |   2 +-
 drivers/gpu/nova-core/falcon/gsp.rs           |   4 +-
 drivers/gpu/nova-core/falcon/sec2.rs          |   2 +-
 drivers/gpu/nova-core/regs.rs                 |   6 +-
 rust/kernel/bitfield.rs                       | 804 ++++++++++++++++++
 rust/kernel/io.rs                             |   1 +
 .../macros.rs => rust/kernel/io/register.rs   | 317 +------
 rust/kernel/lib.rs                            |   1 +
 security/Kconfig.hardening                    |   9 +
 10 files changed, 870 insertions(+), 283 deletions(-)
 create mode 100644 rust/kernel/bitfield.rs
 rename drivers/gpu/nova-core/regs/macros.rs => rust/kernel/io/register.rs (72%)

-- 
2.34.1

On Tue Sep 30, 2025 at 4:45 PM CEST, Joel Fernandes wrote:
>  MAINTAINERS                                   |   7 +
>  drivers/gpu/nova-core/falcon.rs               |   2 +-
>  drivers/gpu/nova-core/falcon/gsp.rs           |   4 +-
>  drivers/gpu/nova-core/falcon/sec2.rs          |   2 +-
>  drivers/gpu/nova-core/regs.rs                 |   6 +-
>  rust/kernel/bitfield.rs                       | 804 ++++++++++++++++++
>  rust/kernel/io.rs                             |   1 +
>  .../macros.rs => rust/kernel/io/register.rs   | 317 +------
>  rust/kernel/lib.rs                            |   1 +
>  security/Kconfig.hardening                    |   9 +
>  10 files changed, 870 insertions(+), 283 deletions(-)
>  create mode 100644 rust/kernel/bitfield.rs
>  rename drivers/gpu/nova-core/regs/macros.rs => rust/kernel/io/register.rs (72%)

I think we have at least three or four potential target trees for this:
driver-core (I/O), drm-rust (Nova), bitmap / Rust.

(I don't know which tree the bitmap stuff would go through, I did not find a
tree entry in the MAINTAINERS file.)

Unless someone thinks otherwise, I'd take it through the drm-rust tree once the
series is ready. This should cause the least conflicts and as a bonus enable Tyr
to use it right away.

On Tue Sep 30, 2025 at 11:45 PM JST, Joel Fernandes wrote:
> Hello!
>
> These patches extract and enhance the bitfield support in the register macro in
> nova to define Rust structures with bitfields. It then moves out the bitfield
> support into the kenrel crate and further enhances it. This is extremely useful
> as it allows clean Rust structure definitions without requiring explicit masks
> and shifts.

The extraction and move in themselves (patches 1-4 and maybe the KUNIT
one) look good to me. For the remainder, it will depend on whether the
BoundedInt idea sticks or not as it changes the design in a way that
makes most of these patches unneeded. In any case I think this can be
worked on after the split and extraction.

Patch 5 should probably be dropped as it has the potential to clear
register fields that are useful to the hardware but have no entry in the
`register!` definition, making read-update-write updates of registers
unpredictable.

On Thu Oct 2, 2025 at 10:24 AM JST, Alexandre Courbot wrote:
> On Tue Sep 30, 2025 at 11:45 PM JST, Joel Fernandes wrote:
>> Hello!
>>
>> These patches extract and enhance the bitfield support in the register macro in
>> nova to define Rust structures with bitfields. It then moves out the bitfield
>> support into the kenrel crate and further enhances it. This is extremely useful
>> as it allows clean Rust structure definitions without requiring explicit masks
>> and shifts.
>
> The extraction and move in themselves (patches 1-4 and maybe the KUNIT
> one) look good to me. For the remainder, it will depend on whether the
> BoundedInt idea sticks or not as it changes the design in a way that
> makes most of these patches unneeded. In any case I think this can be
> worked on after the split and extraction.
>
> Patch 5 should probably be dropped as it has the potential to clear
> register fields that are useful to the hardware but have no entry in the
> `register!` definition, making read-update-write updates of registers
> unpredictable.

Ah, I forgot: please base the next revision on top of drm-rust-next as
we are likely to apply it there.