Re: [PATCH v3 3/3] drm/tyr: add GPU reset infrastructure

On Tue Aug 11, 2026 at 11:47 PM CEST, Daniel Almeida wrote:
> We have a lot of places in our downstream driver where it's not really clear
> whether an &IoMem<'bound> and etc will be available.
>
> E.g.: places like the submit path or the async vm_bind path, both invoked from
> the JobQueue, which runs on its own workqueue in our downstream implementation.
>
> i.e. when the JobQueue calls the driver's "submit to hardware" handler, Tyr needs an
> IoMem to perform the mapping in the vm_bind case, or to write the doorbell
> register in the submit case. Also places using delayed work, which is still
> restricted to 'static workqueues IIUC.
>
> That's what I meant by "Devres we will eventually need in the future". Perhaps
> there is a plan to relax the 'static requirement like what happened recently to
> the IRQ code? Because otherwise my suggestion would be try_access().

Yes, all driver API primitives will properly support this. Having to use
try_access() would be an indicator that something is wrong and we should
probably just remove it.

For instance, workqueue is already being addressed with scoped variants [1];
JobQueue should not have an unbounded lifetime either.

[1] https://lore.kernel.org/all/[email protected]/