dma_fence's backend_ops functions ops->wait() and ops->release() are problematic because they prevent fence producers from unloading. Moreover, they can easily be implemented through simpler means more aligned with the dma_fence contract.
Since the declared goal of dma_fence is to move towards an implementation that supports driver-unload in all circumstances, we must prevent more parties from implementing those callbacks. Deprecate ops->release() and ops->wait() and document what users should do instead. Signed-off-by: Philipp Stanner <[email protected]> --- Changes in v2: - Drop confusing sentence (Christian). --- include/linux/dma-fence.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index dd07d128adc3..388c07d11e70 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -220,6 +220,8 @@ struct dma_fence_ops { /** * @wait: * + * DEPRECATED! + * * Custom wait implementation, defaults to dma_fence_default_wait() if * not set. * @@ -243,6 +245,8 @@ struct dma_fence_ops { /** * @release: * + * DEPRECATED! + * * Called on destruction of fence to release additional resources. * Can be called from irq context. This callback is optional. If it is * NULL, then dma_fence_free() is instead called as the default @@ -254,6 +258,12 @@ struct dma_fence_ops { * * If the callback is implemented the memory backing the dma_fence * object must be freed RCU safe. + * + * Deprecated because it prevents the producer of a fence from + * unloading. No new users must be implemented. Parties with a + * hypothetical need for this callback can instead simply and directly + * perform their custom release operations one RCU grace period after + * they have signaled the fence. */ void (*release)(struct dma_fence *fence); base-commit: 3e32932d3626d0279f9b3531bd648f8c0a16cb08 -- 2.55.0
