Nouveau - Jul 2025 - [PATCH v2] gpu: nova-core: vbios: change PmuLookupTableEntry to relax alignment

Hello, Rhys,

On Mon, Jul 14, 2025 at 04:02:23AM -0700, Rhys Lloyd
wrote:
> Instead of the data field containing a u32 and changing the alignment,
> change data to [u8; 4] and convert to u32 with a helper function.
> Removes another magic number by making the struct the same size as
> the data it needs to read, allowing the use of
> `size_of::<PmuLookupTableEntry>()`
> 
> Signed-off-by: Rhys Lloyd <krakow20 at gmail.com>
> ---
> Changes in v2:
> - get_data helper function renamed to data
> 
> ---
>  drivers/gpu/nova-core/vbios.rs | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/nova-core/vbios.rs
b/drivers/gpu/nova-core/vbios.rs
> index 5b5d9f38cbb3..339c66e63c7e 100644
> --- a/drivers/gpu/nova-core/vbios.rs
> +++ b/drivers/gpu/nova-core/vbios.rs
> @@ -896,21 +896,26 @@ fn try_from(base: BiosImageBase) ->
Result<Self> {
>  struct PmuLookupTableEntry {
>      application_id: u8,
>      target_id: u8,
> -    data: u32,
> +    data: [u8; 4],
Instead of this, could we make the struct as #repr[(C, packed)] or does that
not work for some reason?
>  }
>  
>  impl PmuLookupTableEntry {
>      fn new(data: &[u8]) -> Result<Self> {
> -        if data.len() < 6 {
> +        if data.len() < core::mem::size_of::<Self>() {
This part looks good, and thanks for the fix. Alex beat me to the review but
for the actual fix [1], FWIW:
Reviewed-by: Joel Fernandes <joelagnelf at nvidia.com>

[1] https://lore.kernel.org/all/DBBG2S0ZQAMI.2KK26Z7U58DI8 at nvidia.com/#t

thanks,

 - Joel
>              return Err(EINVAL);
>          }
>  
>          Ok(PmuLookupTableEntry {
>              application_id: data[0],
>              target_id: data[1],
> -            data: u32::from_le_bytes(data[2..6].try_into().map_err(|_|
EINVAL)?),
> +            data: [data[2], data[3], data[4], data[5]],
>          })
>      }
> +
> +    /// Construct a u32 from `self.data`.
> +    fn data(&self) -> u32 {
> +        u32::from_le_bytes(self.data)
> +    }
>  }
>  
>  /// The [`PmuLookupTableEntry`] structure is used to find the
[`PmuLookupTableEntry`] for a given
> @@ -1037,7 +1042,7 @@ fn setup_falcon_data(
>              .find_entry_by_type(FALCON_UCODE_ENTRY_APPID_FWSEC_PROD)
>          {
>              Ok(entry) => {
> -                let mut ucode_offset = entry.data as usize;
> +                let mut ucode_offset = entry.data() as usize;
>                  ucode_offset -= pci_at_image.base.data.len();
>                  if ucode_offset < first_fwsec.base.data.len() {
>                      dev_err!(pdev.as_ref(), "Falcon Ucode offset not
in second Fwsec.\n");
> 
> base-commit: 215a3f91713383a3c0d2da82d223a608a3c17ac1
> prerequisite-patch-id: d80f92d314a0693d4c89ffb7810d9ab6990336fa
> -- 
> 2.50.1
>

On Mon, Jul 14, 2025 at 4:49?PM Joel Fernandes <joelagnelf at nvidia.com>
wrote:
>
> Hello, Rhys,
>
> On Mon, Jul 14, 2025 at 04:02:23AM -0700, Rhys Lloyd wrote:
> > Instead of the data field containing a u32 and changing the alignment,
> > change data to [u8; 4] and convert to u32 with a helper function.
> > Removes another magic number by making the struct the same size as
> > the data it needs to read, allowing the use of
> > `size_of::<PmuLookupTableEntry>()`
> >
> > Signed-off-by: Rhys Lloyd <krakow20 at gmail.com>
> > ---
> > Changes in v2:
> > - get_data helper function renamed to data
> >
> > ---
> >  drivers/gpu/nova-core/vbios.rs | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/nova-core/vbios.rs
b/drivers/gpu/nova-core/vbios.rs
> > index 5b5d9f38cbb3..339c66e63c7e 100644
> > --- a/drivers/gpu/nova-core/vbios.rs
> > +++ b/drivers/gpu/nova-core/vbios.rs
> > @@ -896,21 +896,26 @@ fn try_from(base: BiosImageBase) ->
Result<Self> {
> >  struct PmuLookupTableEntry {
> >      application_id: u8,
> >      target_id: u8,
> > -    data: u32,
> > +    data: [u8; 4],
>
> Instead of this, could we make the struct as #repr[(C, packed)] or does
that
> not work for some reason?
It would probably, but packed structs aren't very nice to work with
because Rust has to be really careful to never generate a reference to
unaligned fields.

Alice