Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 06 Feb 2026 10:32:38 +0100
Philipp Stanner <phasta@mailbox.org> wrote:

> On Thu, 2026-02-05 at 13:16 +0000, Gary Guo wrote:
> > On Thu Feb 5, 2026 at 10:16 AM GMT, Boris Brezillon wrote:  
> > > On Tue,  3 Feb 2026 09:14:01 +0100
> > > Philipp Stanner <phasta@kernel.org> wrote:
> > >   
> > > >   
> 
> […]
> 
> > > > +#[pin_data]
> > > > +pub struct DmaFence<T> {
> > > > +    /// The actual dma_fence passed to C.
> > > > +    #[pin]
> > > > +    inner: Opaque<bindings::dma_fence>,
> > > > +    /// User data.
> > > > +    #[pin]
> > > > +    data: T,  
> > > 
> > > A DmaFence is a cross-device synchronization mechanism that can (and
> > > will)
> > >   
> 
> I'm not questioning the truth behind this statement. They are designed
> to do that. But is that actually being done, currently? I recently
> found that the get_driver_name() callback intended to inform the
> consumer of a fence about who actually issued the fence is only ever
> used by i915.

It's also used by the dma-buf layer to expose info about dma-bufs
through debugfs (see dma_{fence,resv}_describe() and
dma_buf_debug_show()), meaning all GPU drivers adding their fences to
the dma_resv of an imported/exported buffer object should expect to
have their ::get_{driver,timeline}_name() implementation called.