On Fri Sep 25, 2026 at 12:26 PM CEST, Gary Guo wrote: > On Fri Sep 25, 2026 at 9:19 AM BST, Philipp Stanner wrote: >> Replace the warning print with a dev_warn!(). To do so, have the >> FenceContext carry a reference to a Device, protected by the already >> present lifetime. > > Add a lifetime just to do this a print doesn't sound ideal. You could use > `ARef<Device>` instead?
Yes, that's what I recommend in general. Another thing to consider for the DMA fence context specifically, there's two kinds of users. The absolute majority are drivers; there are very few non-driver ones (e.g. drm_crtc), which will remain to be C code for at least quite a while. I think it wouldn't be unreasonable to keep the API driver centric, and in this case it also wouldn't be unreasonable to add the lifetime, as the T will most likely carry it anyway, and even if not it wouldn't make sense for the fence context to outlive driver unbind. That said, we can also use WARN_ON() instead, which avoids the device dependency to begin with and still provides enough information to find the "offender". But as I mentioned previously, I don't consider this that bad of a condition in the first place. Signaling with ECANCELED on drop() seems perfectly reasonable: When a driver does a teardown of the channel (or more generically the execution context) it will follow the RAII pattern, so it will be very natural to just drop the Jobqueue, which will drop all jobs and hence all DriverFence objects. IOW, driver will likely invent a new type that does the same thing on drop, just without the warning. :)
