[PATCH] usb: gadget: f_fs: Remove deprecated dma_fence->ops

[PATCH] usb: gadget: f_fs: Remove deprecated dma_fence->ops

[Philipp Stanner]

The dma_fence_ops function ops->release() has been deprecated because it
prevents drivers from unloading. f_fs's implementation merely frees the
fence. The dma_fence backend performs this deallocation automatically in
the correct manner if ops->release() is not implemented.

The backend simultaneously correctly frees struct ffs_dma_fence since
struct dma_fence is its base class.

Remove ops->release().

Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
 drivers/usb/gadget/function/f_fs.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index c64a268e98a4..e8672b37e890 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1479,18 +1479,9 @@ static const char *ffs_dmabuf_get_timeline_name(struct dma_fence *fence)
 	return "";
 }
 
-static void ffs_dmabuf_fence_release(struct dma_fence *fence)
-{
-	struct ffs_dma_fence *dma_fence =
-		container_of(fence, struct ffs_dma_fence, base);
-
-	kfree(dma_fence);
-}
-
 static const struct dma_fence_ops ffs_dmabuf_fence_ops = {
 	.get_driver_name	= ffs_dmabuf_get_driver_name,
 	.get_timeline_name	= ffs_dmabuf_get_timeline_name,
-	.release		= ffs_dmabuf_fence_release,
 };
 
 static int ffs_dma_resv_lock(struct dma_buf *dmabuf, bool nonblock)
-- 
2.56.0

Re: [PATCH] usb: gadget: f_fs: Remove deprecated dma_fence->ops

[Paul Cercueil]

Hi Philipp,

Le jeudi 29 octobre 2026 à 13:51 +0100, Philipp Stanner a écrit :
> The dma_fence_ops function ops->release() has been deprecated because it
> prevents drivers from unloading. f_fs's implementation merely frees the
> fence. The dma_fence backend performs this deallocation automatically in
> the correct manner if ops->release() is not implemented.
> 
> The backend simultaneously correctly frees struct ffs_dma_fence since
> struct dma_fence is its base class.

For context, this .release() callback was added to avoid the implicit free of
the base class, which IIRC was a request I got during the review process of this
change set.

I'm personally fine with the change, but do we need a "keep this field at the
top" comment for the base class in the ffs_dma_fence struct? Or what's the
policy here?

Cheers,
-Paul

> 
> Remove ops->release().
> 
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
> ---
>  drivers/usb/gadget/function/f_fs.c | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index c64a268e98a4..e8672b37e890 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1479,18 +1479,9 @@ static const char *ffs_dmabuf_get_timeline_name(struct
> dma_fence *fence)
>  	return "";
>  }
>  
> -static void ffs_dmabuf_fence_release(struct dma_fence *fence)
> -{
> -	struct ffs_dma_fence *dma_fence =
> -		container_of(fence, struct ffs_dma_fence, base);
> -
> -	kfree(dma_fence);
> -}
> -
>  static const struct dma_fence_ops ffs_dmabuf_fence_ops = {
>  	.get_driver_name	= ffs_dmabuf_get_driver_name,
>  	.get_timeline_name	= ffs_dmabuf_get_timeline_name,
> -	.release		= ffs_dmabuf_fence_release,
>  };
>  
>  static int ffs_dma_resv_lock(struct dma_buf *dmabuf, bool nonblock)

Re: [PATCH] usb: gadget: f_fs: Remove deprecated dma_fence->ops

[Philipp Stanner]

Hi,

On Thu, 2026-10-29 at 14:19 +0100, Paul Cercueil wrote:
> Hi Philipp,
> 
> For context, this .release() callback was added to avoid the implicit free of
> the base class, which IIRC was a request I got during the review process of this
> change set.

Can't say anything about the request you got, but fences are reference-
counted and the ability to free itself exists since at least
3c3b177a9369 (2014).

From dma_fence's perspective it's certainly the desired canonical
pattern since the release() ops prevents fences from the important
feature of decoupling fence producer and consumer.

> 
> I'm personally fine with the change, but do we need a "keep this field at the
> top" comment for the base class in the ffs_dma_fence struct? Or what's the
> policy here?

When I got into the kernel I was told that it's common practice to
always have the base class as the first element. That also allows for
obtaining the parent class by a mere pointer-cast instead of
container_of.

But the reality is also that some users are not aware of this rule. I
can document it in a v2 if you like.

Regards,
Philipp

Re: [PATCH] usb: gadget: f_fs: Remove deprecated dma_fence->ops

[Paul Cercueil]

Le jeudi 29 octobre 2026 à 14:49 +0100, Philipp Stanner a écrit :
> Hi,
> 
> On Thu, 2026-10-29 at 14:19 +0100, Paul Cercueil wrote:
> > Hi Philipp,
> > 
> > For context, this .release() callback was added to avoid the implicit free
> > of
> > the base class, which IIRC was a request I got during the review process of
> > this
> > change set.
> 
> Can't say anything about the request you got, but fences are reference-
> counted and the ability to free itself exists since at least
> 3c3b177a9369 (2014).

Yes, it already existed when I wrote the code and I was requested to make it
explicit. Not trying to make a point here, just stating the reasons why it was
written that way.

> From dma_fence's perspective it's certainly the desired canonical
> pattern since the release() ops prevents fences from the important
> feature of decoupling fence producer and consumer.

ACK.

> > I'm personally fine with the change, but do we need a "keep this field at
> > the
> > top" comment for the base class in the ffs_dma_fence struct? Or what's the
> > policy here?
> 
> When I got into the kernel I was told that it's common practice to
> always have the base class as the first element. That also allows for
> obtaining the parent class by a mere pointer-cast instead of
> container_of.
> 
> But the reality is also that some users are not aware of this rule. I
> can document it in a v2 if you like.

Let's wait on feedback from more people. I don't have a strong opinion either
way.

Cheers,
-Paul