linux-kernel - Re: [PATCH v6 4/5] rust: Move register and bitfield macros out of Nova

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5a5bd549-f5b7-41ec-b493-bda427d1218f@de.bosch.com>
Date: Thu, 9 Oct 2025 08:59:56 +0200
From: Dirk Behme <dirk.behme@...bosch.com>
To: Joel Fernandes <joelagnelf@...dia.com>, <linux-kernel@...r.kernel.org>,
	<rust-for-linux@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
	<dakr@...nel.org>, <acourbot@...dia.com>
CC: Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, "Gary
 Guo" <gary@...yguo.net>, <bjorn3_gh@...tonmail.com>, Benno Lossin
	<lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl
	<aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, David Airlie
	<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>, John Hubbard <jhubbard@...dia.com>,
	Timur Tabi <ttabi@...dia.com>, <joel@...lfernandes.org>, Elle Rhumsaa
	<elle@...thered-steel.dev>, Yury Norov <yury.norov@...il.com>, Daniel Almeida
	<daniel.almeida@...labora.com>, Andrea Righi <arighi@...dia.com>,
	<nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 4/5] rust: Move register and bitfield macros out of
 Nova

On 03/10/2025 17:47, Joel Fernandes wrote:
> Out of broad need for the register and bitfield macros in Rust, move
> them out of nova into the kernel crate. Several usecases need them (Nova
> is already using these and Tyr developers said they need them).
> 
> bitfield moved into kernel crate - defines bitfields in Rust.
> register moved into io module - defines hardware registers and accessors.
> 
> Reviewed-by: Alexandre Courbot <acourbot@...dia.com>
> Reviewed-by: Elle Rhumsaa <elle@...thered-steel.dev>
> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
> ---
>   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/nova_core.rs            |  3 -
>   drivers/gpu/nova-core/regs.rs                 |  6 +-
>   .../gpu/nova-core => rust/kernel}/bitfield.rs | 27 ++++-----
>   rust/kernel/io.rs                             |  1 +
>   .../macros.rs => rust/kernel/io/register.rs   | 58 ++++++++++---------
>   rust/kernel/lib.rs                            |  1 +
>   9 files changed, 54 insertions(+), 50 deletions(-)
>   rename {drivers/gpu/nova-core => rust/kernel}/bitfield.rs (91%)
>   rename drivers/gpu/nova-core/regs/macros.rs => rust/kernel/io/register.rs (93%)
> 
...
> index c0a5194e8d97..c24d956f122f 100644
> --- a/drivers/gpu/nova-core/regs/macros.rs
> +++ b/rust/kernel/io/register.rs

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?

* In my example I used io.try_write*() and io.try_read*() for the 
register access. What is the relationship between these and the 
register!() accessors (e.g. from the examples BOOT_0::read(&bar);)? Will 
both stay? When to use which?

Note: Due to the file move obviously not the full content of the "new" 
file register.rs is shown in this patch. Therefore, let me try it this 
way, citing from register.rs:

-- cut --
...
/// This defines a `BOOT_0` type which can be read or written from 
offset `0x100` of an `Io`
/// region
....
/// ```ignore
/// // Read from the register's defined offset (0x100).
/// let boot0 = BOOT_0::read(&bar);
-- cut --

* What is "&bar" in this example? Is it the `Io` region the explanation 
talks about?

Thanks!

Dirk


[1] 
https://lore.kernel.org/rust-for-linux/dd34e5f4-5027-4096-9f32-129c8a067d0a@de.bosch.com/

The registers:

const TSTR: usize =  0x4; //  8 Bit register
const TCOR: usize =  0x8; // 32 Bit register
const TCNT: usize =  0xC; // 32 Bit register
const TCR:  usize = 0x10; // 16 Bit register