linux-kernel - Re: [PATCH v8 2/6] gpu: nova-core: prepare Spec and Revision types for boot0/boot42

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] [day] [month] [year] [list]
Message-ID: <d4723c7a-b0ef-444e-a72a-6a083db8457d@nvidia.com>
Date: Fri, 14 Nov 2025 16:49:58 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>,
 Danilo Krummrich <dakr@...nel.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 Alistair Popple <apopple@...dia.com>, Edwin Peer <epeer@...dia.com>,
 Zhi Wang <zhiw@...dia.com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Bjorn Helgaas <bhelgaas@...gle.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>,
 nouveau@...ts.freedesktop.org, rust-for-linux@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>,
 Nouveau <nouveau-bounces@...ts.freedesktop.org>
Subject: Re: [PATCH v8 2/6] gpu: nova-core: prepare Spec and Revision types
 for boot0/boot42

On 11/14/25 6:37 AM, Alexandre Courbot wrote:
> On Fri Nov 14, 2025 at 11:41 AM JST, John Hubbard wrote:
...
> Something felt a bit off with this diff, and I only realized why now.
> 
> We are moving, for no good reason, the creation of `Revision` into the
> boot0 (and later boot42) register, which forces us to increase the
> visibility of its fields.
> 
> And while `Revision` is now created by a method of the register it
> originates from, `Spec` for some reason isn't, and we even add a
> `TryFrom` implementation for it here. This creates an asymmetry that has
> no justification afaict.
> 
> Instead, what if we replaced this `from_boot0` method by a `From<BOOT0>`
> implementation? That way, we have consistency in how we derive our chip
> information structures, and this patch can be reduced to this (with the
> other changes below):

Yes, that allows leaving Revision's members private, which shows that
we're laying out the objects in a better way.

I've implemented this for v9.

> 
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index dfeba9d5d8f6..57c20d1e7274 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -147,8 +147,8 @@ pub(crate) struct Revision {
>      minor: u8,
>  }
> 
> -impl Revision {
> -    fn from_boot0(boot0: regs::NV_PMC_BOOT_0) -> Self {
> +impl From<regs::NV_PMC_BOOT_0> for Revision {
> +    fn from(boot0: regs::NV_PMC_BOOT_0) -> Self {
>          Self {
>              major: boot0.major_revision(),
>              minor: boot0.minor_revision(),
> @@ -162,10 +162,9 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
>      }
>  }
> 
> -/// Structure holding the metadata of the GPU.
> +/// Structure holding a basic description of the GPU: `Chipset` and `Revision`.
>  pub(crate) struct Spec {
>      chipset: Chipset,
> -    /// The revision of the chipset.
>      revision: Revision,
>  }
> 
> @@ -173,9 +172,17 @@ impl Spec {
>      fn new(bar: &Bar0) -> Result<Spec> {
>          let boot0 = regs::NV_PMC_BOOT_0::read(bar);
> 
> +        Spec::try_from(boot0)
> +    }
> +}
> +
> +impl TryFrom<regs::NV_PMC_BOOT_0> for Spec {
> +    type Error = Error;
> +
> +    fn try_from(boot0: regs::NV_PMC_BOOT_0) -> Result<Self> {
>          Ok(Self {
>              chipset: boot0.chipset()?,
> -            revision: Revision::from_boot0(boot0),
> +            revision: boot0.into(),
>          })
>      }
>  }
> 
> ... and the subsequent patches also get some simplification.
> 
>>  }
>>  
>>  impl fmt::Display for Revision {
>> @@ -162,10 +153,9 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
>>      }
>>  }
>>  
>> -/// Structure holding the metadata of the GPU.
>> +/// Structure holding a basic description of the GPU: `Architecture`, `Chipset` and `Revision`.
> 
> There is no `Architecture` in this structure though?
> 
>>  pub(crate) struct Spec {
>>      chipset: Chipset,
>> -    /// The revision of the chipset.
>>      revision: Revision,
>>  }
>>  
>> @@ -173,9 +163,17 @@ impl Spec {
>>      fn new(bar: &Bar0) -> Result<Spec> {
>>          let boot0 = regs::NV_PMC_BOOT_0::read(bar);
>>  
>> +        Spec::try_from(boot0)
>> +    }
>> +}
>> +
>> +impl TryFrom<regs::NV_PMC_BOOT_0> for Spec {
>> +    type Error = Error;
>> +
>> +    fn try_from(boot0: regs::NV_PMC_BOOT_0) -> Result<Self> {
>>          Ok(Self {
>>              chipset: boot0.chipset()?,
>> -            revision: Revision::from_boot0(boot0),
>> +            revision: boot0.revision(),
>>      }
>>          })
>>  }
>> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
>> index 934003cab8a8..8c9af3c59708 100644
>> --- a/drivers/gpu/nova-core/regs.rs
>> +++ b/drivers/gpu/nova-core/regs.rs
>> @@ -24,7 +24,8 @@
>>      },
>>      gpu::{
>>          Architecture,
>> -        Chipset, //
>> +        Chipset,
>> +        Revision, //
>>      },
>>      num::FromSafeCast,
>>  };
>> @@ -56,6 +57,14 @@ pub(crate) fn chipset(self) -> Result<Chipset> {
>>              })
>>              .and_then(Chipset::try_from)
>>      }
>> +
>> +    /// Returns the revision information of the chip.
>> +    pub(crate) fn revision(self) -> Revision {
>> +        Revision {
>> +            major: self.major_revision(),
>> +            minor: self.minor_revision(),
>> +        }
>> +    }
> 
> With the `From<BOOT0> for Revision` implementation we can also drop this
> method.

Yes. Done.


thanks,
-- 
John Hubbard