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

[Paul Cercueil <paul@crapouillou.net>]

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