linux-kernel - Re: [PATCH v7.1 2/4] gpu: nova-core: bitfield: Move bitfield-specific code from register! into new macro

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: <0e592a2d-6c0a-4dab-b16c-ff994917af9a@nvidia.com>
Date: Mon, 20 Oct 2025 16:16:28 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>, Yury Norov
 <yury.norov@...il.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
 "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
 Alexandre Courbot <acourbot@...dia.com>, 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" <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>,
 Timur Tabi <ttabi@...dia.com>,
 "joel@...lfernandes.org" <joel@...lfernandes.org>,
 Elle Rhumsaa <elle@...thered-steel.dev>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 "nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
 Edwin Peer <epeer@...dia.com>
Subject: Re: [PATCH v7.1 2/4] gpu: nova-core: bitfield: Move bitfield-specific
 code from register! into new macro

On 10/20/25 4:07 PM, Danilo Krummrich wrote:
> On Tue Oct 21, 2025 at 12:50 AM CEST, John Hubbard wrote:
>> On 10/16/25 12:39 PM, John Hubbard wrote:
>>> On 10/16/25 12:34 PM, Danilo Krummrich wrote:
>>>> On Thu Oct 16, 2025 at 9:28 PM CEST, Joel Fernandes wrote:
>>>>>> On Oct 16, 2025, at 1:48 PM, Yury Norov <yury.norov@...il.com> wrote:
>>>>>> On Thu, Oct 16, 2025 at 11:13:21AM -0400, Joel Fernandes wrote:
>>> ...
>>>> While I'm not super opinionated for general bitfields, for the register!()
>>>> infrastructure I very much prefer the hi:lo notation, as this is the common
>>>> notation in datasheets and TRMs.
>>>>
>>>> However, if we use hi:lo, we should use it decending, i.e.:
>> (restored from the email thread):
>>
>> 	bitfield! {
>> 	    struct ControlReg {
>> 	        7:5 state as u8 => State;
>> 	        3:0 mode as u8 ?=> Mode;
>> 	    }
>> 	}>>
>>>
>>> Sure, descending works.
>>
>> Oops! I need to correct myself. After reviewing most of Joel Fernandes'
>> latest patchset ([PATCH 0/7] Pre-requisite patches for mm and irq in
>> nova-core) [1], I remember that the HW documentation is written in
>> ascending order.
>>
>> For one example (out of countless hundreds or thousands), please see [2].
>> Considering that I actually pushed this file up to github just a few
>> years ago, it's rather silly of me to forget this basic truth. :)
>>
>> We really want to stay close to the HW documentation, and so, all other
>> things being (nearly) equal, this means that we should prefer ascending
>> field order, if that's OK with everyone.
> 
> But that's OpenRM specific, I'm pretty sure when you look at internal datasheets
> and TRMs you will find hi:lo with decending order, for instance [3] page 1672

TRM is Tegra. This is gradually going away, from our point of view, as
the larger, older RM (Open RM) driver subsumes things.

Open RM follows the main dGPU ref manuals, and we have piles of those
and they all apply to Nova.

None of the TRM stuff applies to Nova.

> (clicked a random location in the scroll bar. :).
> 
> Besides, I think that hi:lo with ascending order is confusing. It should either
> be hi:lo decending or lo:hi ascending.
> 
> For registers the common one is the former.
> 
>> [1] https://lore.kernel.org/20251020185539.49986-1-joelagnelf@nvidia.com
>> [2] https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/ampere/ga102/dev_ce.ref.txt
> [3] https://developer.nvidia.com/downloads/orin-series-soc-technical-reference-manual/