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 for Android: free password hash cracker in your pocket

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

Message-ID: <da74ab79-2b35-4e64-8032-5c14be5ea089@nvidia.com>
Date: Mon, 20 Oct 2025 17:04:58 -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:22 PM, Danilo Krummrich wrote:
> On Tue Oct 21, 2025 at 1:16 AM CEST, John Hubbard wrote:
>> 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:
>>>>> ...
>>> 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.
> 
> My point is less about NVIDIA TRMs, it's about that this is uncommon in general,
> OpenRM is the one being special here.
> 
> So, the question for me is do we care more about consistency throughout the
> kernel, or do we care about consistency between a driver and it's uncommon
> reference manual.

Yes, I think that is the key point.

> 
> I think consistency throughout the kernel is more important.
> 

Perhaps, but may I point out that there are countless thousands of lines
of HW ref manuals to deal with? GPUs are uncommonly complicated devices,
and I've spent a lot of time in this area, being awed at the sheer volume
of HW documentation.

And there are hundreds of engineers who today work on GSP and Open RM,
some of whom I expect to eventually end up working on Nova.

So looking ahead, I'd be much more comfortable saying something like
this:

"Nova and its associated GPU HW manuals are special snowflakes that
use a particular documenation style. We'll allow them to deviate from
other kernel conventions in this area."

Yes? Please? :)

thanks,
-- 
John Hubbard

>>> (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/
>