On Thu, 19 Feb 2026 13:52:43 +0100 Christian König <[email protected]> wrote:
> On 2/13/26 15:22, Boris Brezillon wrote: > >> --- > >> drivers/dma-buf/dma-fence.c | 16 ++++++++++++---- > >> include/linux/dma-fence.h | 4 ++-- > >> 2 files changed, 14 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > >> index de9bf18be3d4..ba02321bef0b 100644 > >> --- a/drivers/dma-buf/dma-fence.c > >> +++ b/drivers/dma-buf/dma-fence.c > >> @@ -371,6 +371,14 @@ void dma_fence_signal_timestamp_locked(struct > >> dma_fence *fence, > >> &fence->flags))) > >> return; > >> > >> + /* > >> + * When neither a release nor a wait operation is specified set the ops > >> + * pointer to NULL to allow the fence structure to become independent > >> + * from who originally issued it. > > > > I think this deserves some comment in the dma_fence_ops doc, so that > > people know what to expect when they implement this interface. > There was already a warning added like ~5years ago that implementations > shouldn't use the wait callback. > > Completely independent of this patch set here we already had tons of trouble > with it because it can't take into account when userpsace waits for multiple > fences from different implementations. > > It potentially was never a good idea to have in the first place, we basically > only had it because radeon (and IIRC nouveau at that point) depended on it. Fair enough. If it's flagged deprecated already, let's keep things like that.
