Alexandre Courbot
2025-Oct-02 01:24 UTC
[PATCH v5 0/9] Introduce bitfield and move register macro to rust/kernel/
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.
Alexandre Courbot
2025-Oct-02 01:26 UTC
[PATCH v5 0/9] Introduce bitfield and move register macro to rust/kernel/
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.