Re: [PATCH v5 01/11] gpu: nova-core: Add public driver API to nova-core

[Alistair Popple <apopple@nvidia.com>]

On 2026-09-01 at 17:14 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Tue Sep 1, 2026 at 9:07 AM CEST, Alistair Popple wrote:
> > On 2026-09-01 at 06:42 +1000, Gary Guo <gary@garyguo.net> wrote...
> >> On Mon Aug 31, 2026 at 9:08 PM BST, Danilo Krummrich wrote:
> >> > On Fri Aug 28, 2026 at 5:35 AM CEST, Alistair Popple wrote:
> >> >> +/// API handle for the auxiliary bus child drivers to interact with nova-core.
> >> >> +pub struct NovaCoreApi<'bound> {
> >> >> +    #[expect(unused)]
> >> >> +    pub(crate) gpu: Pin<&'bound Gpu<'bound>>,
> >> >> +}
> >> >> +
> >> >> +impl NovaCoreApi<'_> {
> >> >> +    /// Obtain a [`NovaCoreApi`] handle from an auxiliary device registered
> >> >> +    /// by nova-core.
> >> >> +    pub fn of(adev: &auxiliary::Device<Bound>) -> Result<Pin<&NovaCoreApi<'_>>> {
> >> >> +        adev.registration_data::<CovariantForLt!(NovaCoreApi<'_>)>()
> >> >> +    }
> >> >> +}
> >> >
> >> > CovariantForLt does not hold anymore on latest drm-rust-next, as Cmdq has a
> >> > Mutex. So, this needs ForLt now and therefore the approach that I shared in [1]
> >> > a while ago. I applied the changes in [2] to fix it up.
> >
> > I can see why the mutex means covariance no longer holds, but I would kind
> > of also expect it to not compile given it surely can't be safe here to treat
> > an invariant type as covariant. Is this just a limitation of the current
> > CovariantForLt implementation not being able to prove covariance or am I missing
> > something else? Thanks.
> 
> Well, it did not compile (as expected) on my end, which is how I caught it.
> What's your base revision?

I'm on drm-rust-next which I believe is:

commit b705c185105762676aa6ec16cf976101df87cc35 (drm-rust/for-linux-next, drm-rust/drm-rust-next)
Author: Alexandre Courbot <acourbot@nvidia.com>
Date:   Thu Jul 23 22:54:37 2026 +0900

    gpu: nova-core: fix incorrect naming/framing of GSP-FMC firmware

Reason it compiles is because the the Gsp has no lifetime parameter in the chain
to the mutex:

Gpu<'a> -> GspResources<'a> -> Gsp -> Cmdq -> Mutex<CmdqInner>

Which I think means using ConvariantForLt is fine in this context, unless there
is some other change coming which requires the lifetime. John's IRQ series hides
the Cmdq behind an Arc<> but that still works as there's no lifetime parameter
there either.

Not sure why you're seeing failures, what base revision are you using? (and
apologies, next time I will tell git to add the base sha1 to the series).

 - Alistair