Re: [PATCH v4 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter

[Alistair Popple <apopple@nvidia.com>]

On 2026-08-18 at 06:11 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> > Currently nova-drm reads the VRAM BAR size directly from the PCIe device
> > which requires trying to cast the parent device into a PCIe device. This
> > obviously requires the parent device to actually be a PCIe bus device.
> > Whilst that is true today it may not always be the case, and there
> > is no reason to make this assumption now that NovaCoreApi can hold a
> > reference to the bound PCIe device.
> >
> > So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
> > parameter.
> >
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> 
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> 
> > @@ -33,16 +30,13 @@ fn open(_dev: &NovaDevice) -> Result<Pin<KBox<Self>>> {
> >  impl File {
> >      /// IOCTL: get_param: Query GPU / driver metadata.
> >      pub(crate) fn get_param(
> > -        dev: &NovaDevice<Registered>,
> > -        _reg_data: &DrmRegData<'_>,
> > +        _dev: &NovaDevice<Registered>,
> > +        reg_data: &DrmRegData<'_>,
> >          getparam: &mut uapi::drm_nova_getparam,
> >          _file: &drm::File<File>,
> >      ) -> Result<u32> {
> > -        let adev: &auxiliary::Device<Bound> = dev.as_ref();
> > -        let pdev: &pci::Device<Bound> = adev.parent().try_into()?;
> > -
> >          let value = match getparam.param as u32 {
> > -            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => pdev.resource_len(1)?,
> > +            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => reg_data.api.bar1_size()?,
> >              _ => return Err(EINVAL),
> >          };
> 
> That's much cleaner, thanks for adding this patch!

No problem! Agree it's much nicer.

> Once this landed we can remove the
> 
> 	impl<Ctx: device::DeviceContext> TryFrom<&device::Device<Ctx>> for &Device<Ctx>
> 
> impl in rust/kernel/pci.rs. (I think platform should have the same impl to get
> rid of independently.)
> 
> If your are interested, feel free to send a follow-up patch (or include it in
> this series).

Happy to do either. Seems like it might be easiest just to add it to this
series so will add it to v5.