On 2026-09-01 at 17:14 +1000, Danilo Krummrich <[email protected]> wrote... > On Tue Sep 1, 2026 at 9:07 AM CEST, Alistair Popple wrote: > > On 2026-09-01 at 06:42 +1000, Gary Guo <[email protected]> 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 <[email protected]> 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
