Message-Id: <DG120QJCVQDS.1E3ZZ4IVVU8Q2@nvidia.com>
Date: Thu, 29 Jan 2026 20:59:04 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Joel Fernandes" <joelagnelf@...dia.com>
Cc: "John Hubbard" <jhubbard@...dia.com>, "Danilo Krummrich"
 <dakr@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>, "Daniel Almeida"
 <daniel.almeida@...labora.com>, "Miguel Ojeda" <ojeda@...nel.org>, "Boqun
 Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Trevor
 Gross" <tmgross@...ch.edu>, "Yury Norov" <yury.norov@...il.com>, "Alistair
 Popple" <apopple@...dia.com>, "Timur Tabi" <ttabi@...dia.com>, "Edwin Peer"
 <epeer@...dia.com>, "Eliot Courtney" <ecourtney@...dia.com>, "Dirk Behme"
 <dirk.behme@...bosch.com>, "Steven Price" <steven.price@....com>,
 <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 5/7] rust: io: add `register!` macro

On Thu Jan 29, 2026 at 2:56 AM JST, Joel Fernandes wrote:
> On Wed, 28 Jan 2026, Alexandre Courbot wrote:
>> So these setters are really part of the `bitfield!` API. Bitfields are,
>> at the end of the day, just integers which we will very likely want to
>> declare constants of out of individual const field values. This can only
>> be done by using const methods, and a const `Bounded` needs to validate
>> its constraints at build time, which requires the
>> `Bounded::new::<VALUE>()` constructor, and by transition
>> similarly-shaped setters to set fields at const time.
>
> I think you run into that issue because the setter requires to do `.into()`
> to do the bounded conversion.

Precisely. Without that conversion, the public field setter could just
forward to the private one, which is const.

>
> If we accept Bounded type in the setter directly instead, it
> should allow to keep the API simple. The advantage is it keeps the API naming
> simple. with_<field>() which accepts Bounded type, that's the contract. The
> trade off is the call-site can be a bit more icky but I wonder how much of an
> issue that really is (it really depends on usage).

I have tried converting the current macro to this idea, and this results
in quite a few `.into()` calls. Notably, I find the following a bit (pun
intended) annoying:

    r.with_start(true.into())

`start` is a 1-bit bitfield, so it should accept a boolean, but here we
cannot pass it directly.

So I am not sure that I prefer this over the current generic argument.
In any case, this exercice has revealed that even if we adopt this idea,
the issue won't be entirely solved because of the `=>` and `?=>` field
conversions.

For such fields, performing an `into()` or `try_into()` is mandatory, as
that's how the argument is converted to the Bounded internally. So
pursuing const-purity at the moment is futile anyway, at least until we
get const trait methods.

Which leaves the original problem: how do we avoid invoking the awkward
`Bounded` constructor for const field values. And AFAICT, taking the
`Bounded` directly still requires us to build it, which requires us to
specify the backing type explicitly as that's the only way for the
compiler to know which constructor to call. So in terms of API
convenience I guess the `with_`/`with_const_` combo remains the best bet
for now.

>
> I wrote a simple program to confirm the same function will work for both const
> and non-const parameters. Actually the caller does not even need to specific
> the bounded int size at the call site, it gets inferred. So we don't even need
> a bounded! macro.
>
> struct Bounded<const BITS: u32>(u32);

For this example yes, because you have hardcoded the `Bounded` to be
32 bits, but I have tested this against the version in the kernel and it
still requires the fully-specified constructor.

Powered by blists - more mailing lists