Le lundi 29 janvier 2024 à 14:17 +0100, Christian König a écrit :
Am 29.01.24 um 14:06 schrieb Paul Cercueil:
Hi Christian,
Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
> + iio_buffer_dmabuf_put(attach); > + > +out_dmabuf_put: > + dma_buf_put(dmabuf); As below. Feels like a __free(dma_buf_put) bit of magic would be a nice to have.
I'm working on the patches right now, just one quick question.
Having a __free(dma_buf_put) requires that dma_buf_put is first "registered" as a freeing function using DEFINE_FREE() in <linux/dma- buf.h>, which has not been done yet.
That would mean carrying a dma-buf specific patch in your tree, are you OK with that?
Needs an ACK from appropriate maintainer, but otherwise I'm fine doing so. Alternative is to circle back to this later after this code is upstream.
Separate patches for that please, the autocleanup feature is so new that I'm not 100% convinced that everything works out smoothly from the start.
Separate patches is a given, did you mean outside this patchset? Because I can send a separate patchset that introduces scope-based management for dma_fence and dma_buf, but then it won't have users.
Outside of the patchset, this is essentially brand new stuff.
IIRC we have quite a number of dma_fence selftests and sw_sync which is basically code inside the drivers/dma-buf directory only there for testing DMA-buf functionality.
Convert those over as well and I'm more than happy to upstream this change.
Well there is very little to convert there; you can use scope-based management when the unref is done in all exit points of the functional block, and the only place I could find that does that in drivers/dma- buf/ was in dma_fence_chain_enable_signaling() in dma-fence-chain.c.
Cheers, -Paul