On Thu, Oct 2, 2025 at 12:47 AM Maxime Ripard mripard@redhat.com wrote:
On Thu, Sep 11, 2025 at 03:49:43PM +0200, Jens Wiklander wrote:
Export the dma-buf heap functions to allow them to be used by the OP-TEE driver. The OP-TEE driver wants to register and manage specific secure DMA heaps with it.
Reviewed-by: Sumit Garg sumit.garg@oss.qualcomm.com Reviewed-by: T.J. Mercier tjmercier@google.com Acked-by: Sumit Semwal sumit.semwal@linaro.org Signed-off-by: Jens Wiklander jens.wiklander@linaro.org
drivers/dma-buf/dma-heap.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 3cbe87d4a464..8ab49924f8b7 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -11,6 +11,7 @@ #include <linux/dma-buf.h> #include <linux/dma-heap.h> #include <linux/err.h> +#include <linux/export.h> #include <linux/list.h> #include <linux/nospec.h> #include <linux/syscalls.h> @@ -202,6 +203,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap) { return heap->priv; } +EXPORT_SYMBOL_NS_GPL(dma_heap_get_drvdata, "DMA_BUF_HEAP");
/**
- dma_heap_get_name - get heap name
@@ -214,6 +216,7 @@ const char *dma_heap_get_name(struct dma_heap *heap) { return heap->name; } +EXPORT_SYMBOL_NS_GPL(dma_heap_get_name, "DMA_BUF_HEAP");
/**
- dma_heap_add - adds a heap to dmabuf heaps
@@ -303,6 +306,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) kfree(heap); return err_ret; } +EXPORT_SYMBOL_NS_GPL(dma_heap_add, "DMA_BUF_HEAP");
It's not clear to me why we would need to export those symbols.
As far as I know, heaps cannot be removed, and compiling them as module means that we would be able to remove them.
Now, if we don't expect the users to be compiled as modules, then we don't need to export these symbols at all.
Am I missing something?
For things like distro kernels (or in Android's case, the GKI), there's a benefit for modules that can be loaded permanently (not having a module_exit hook). One doesn't have to bloat the base kernel image/memory usage for everyone, while still not having to necessarily deal with complications from module unloading issues.
thanks -john
linaro-mm-sig@lists.linaro.org