linux-kernel - Re: [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer regions required for GSP

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: <33168c6e-0dd9-47f8-865f-061be48d48f2@nvidia.com>
Date: Fri, 29 Aug 2025 22:46:54 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, 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>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 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>
Cc: Alistair Popple <apopple@...dia.com>,
 Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer
 regions required for GSP

On 8/29/25 5:59 PM, Alexandre Courbot wrote:
> On Sat Aug 30, 2025 at 8:30 AM JST, John Hubbard wrote:
>> On 8/25/25 9:07 PM, Alexandre Courbot wrote:
>> ...
>> We only support one version of the firmware. And in the coming months,
>> that one version will have a different version number.
>>
>> Given those constraints, we should simply remove most (all?) of the "r570_144::"
>> namespace qualifiers in the code, starting here.
>>
>> That way, we get:
>>
>> a) A small diff, instead of a huge one, when we update to a new firmware
>>     version.
>>
>> b) Shorter, cleaner symbols everywhere: GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB
>>     instead of r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB, for example.
> 
> `nvfw` is the module that is supposed to abstract the currently
> supported firmware version - but in order to provide this abstraction,
> it needs to refer the items in question. :) I don't see how we could
> avoid these qualifiers short of having a `use r750_144::*` which could
> result into name collisions.

My idea here was: "what name collisions?". There shouldn't be any.
Because again, there is only one firmware version supported at a time.

> 
> But maybe we can do a module alias to reduce the diff once the version
> changes:
> 
>      use r570_144 as fwbindings;
>      ...
> 
>      pub(crate) const LIBOS2_PARAMS: LibosParams = LibosParams {
>          carveout_size: fwbindings::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS2 as u64,
> 
> Is that what you had in mind?

Not initially, but it would address most of what bothered me here,
which is having a particular version number all over everywhere.


thanks,
-- 
John Hubbard