Message-Id: <DDCFLM3P5MCC.NEBRVTU7X2G3@kernel.org>
Date: Wed, 08 Oct 2025 00:08:59 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Joel Fernandes" <joelagnelf@...dia.com>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Yury Norov"
 <yury.norov@...il.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
 "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>,
 "Daniel Almeida" <daniel.almeida@...labora.com>, "Andrea Righi"
 <arighi@...dia.com>, <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to
 rust/kernel/

On Tue Oct 7, 2025 at 11:08 PM CEST, Joel Fernandes wrote:
> Danilo, Yuri, Miguel, John, all,
>
> On 10/7/2025 9:16 AM, Danilo Krummrich wrote:
>> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
>>> Because letting it fully mature within nova-core also has the drawback
>>> that we might miss the perspective of other potential users, which may
>>> make us draw ourselves into a corner that will make the macro less
>>> useful generally speaking. We are at a stage where we can still make
>>> design changes if needed, but we need to hear from other users, and
>>> these won't come as long as the macro is in nova-core.
>> 
>> There are two different things here that are getting mixed up a bit.
>> 
>>   (1) Moving the register!() code out of nova-core to make it accessible for
>>       other drivers.
>> 
>>   (2) Generalize the bitfield implementation that so far is baked into the
>>       register!() code.
>> 
>> Both of those make sense, but they don't have to happen at the same time
>> necessarily.
>> 
>> Now, I'm not saying that we necessarily have to change the approach here. The
>> current merge window isn't even closed, so we have plently of time left, i.e.
>> there's no rush with with patch series.
>> 
>> However, if it helps, I'm perfectly fine to take the register!() implementation
>> into the I/O entry in a first step and in a second step generalize the bitfield
>> implementation and move it out of the register!() code.
>> 
>> Again, there's no rush as far as I'm concerned, yet the latter approach might
>> add a bit more structure and hence run a bit smoother.
>
> In my view it is better to move both bitfield and register macros together
> because if we only moved register, it means we would have no bitfield support
> for the page table / mm use case I just posted a patch for (which is why I
> started looking into Bitfield support initially) unless we create a copy of just
> the bitfield code within nova which we definitely shouldn't I think. So I think
> it is best to move both.

Again, fine for me either way, but I wanted to open the possibility.

Typically, things run more smoothly when focusing on one thing at a time.
Especially when one thing is done to unblock something else, while the other
things needs some more discussion and might require a more slow-paced approach.)

(Slightly off-topic: Regarding the bitfields for page table management: Are we
sure that we can use raw bitfields for this? I.e. will we always be able to
configure the GPU to match CPU endianness?)

> For the IO (register macro) change, I can add add an entry to the existing IO
> record.

I don't think any changes are needed, it should be covered by just moving it to
rust/kernel/io/register.rs.

Thanks,
Danilo

Powered by blists - more mailing lists