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]/
