Hi,
The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules.
It's generally a good idea if possible, including for the already existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code.
Let me know what you think, Maxime
1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@li...
Signed-off-by: Maxime Ripard mripard@kernel.org --- Maxime Ripard (7): dma: contiguous: Turn heap registration logic around mm: cma: Export cma_alloc and cma_release mm: cma: Export cma_get_name mm: cma: Export dma_contiguous_default_area dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module
drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 5 +++++ kernel/dma/contiguous.c | 27 +++++++++++++++++++++++++-- mm/cma.c | 3 +++ 7 files changed, 46 insertions(+), 20 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a
Best regards,
The CMA heap instantiation was initially developed by having the contiguous DMA code call into the CMA heap to create a new instance every time a reserved memory area is probed.
Turning the CMA heap into a module would create a dependency of the kernel on a module, which doesn't work.
Let's turn the logic around and do the opposite: store all the reserved memory CMA regions into the contiguous DMA code, and provide an iterator for the heap to use when it probes.
Signed-off-by: Maxime Ripard mripard@kernel.org --- drivers/dma-buf/heaps/cma_heap.c | 18 ++---------------- include/linux/dma-map-ops.h | 5 +++++ kernel/dma/contiguous.c | 26 ++++++++++++++++++++++++-- 3 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index bd3370b9a3f6d4e18885a1d0e8ba3f659b85ef47..f8a3d87f3ccee9630383ba28502eb40b10671cc2 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -28,23 +28,10 @@ #include <linux/slab.h> #include <linux/vmalloc.h>
#define DEFAULT_CMA_NAME "default_cma_region"
-static struct cma *dma_areas[MAX_CMA_AREAS] __initdata; -static unsigned int dma_areas_num __initdata; - -int __init dma_heap_cma_register_heap(struct cma *cma) -{ - if (dma_areas_num >= ARRAY_SIZE(dma_areas)) - return -EINVAL; - - dma_areas[dma_areas_num++] = cma; - - return 0; -} - struct cma_heap { struct dma_heap *heap; struct cma *cma; };
@@ -412,22 +399,21 @@ static int __init __add_cma_heap(struct cma *cma, const char *name) }
static int __init add_cma_heaps(void) { struct cma *default_cma = dev_get_cma_area(NULL); + struct cma *cma; unsigned int i; int ret;
if (default_cma) { ret = __add_cma_heap(default_cma, DEFAULT_CMA_NAME); if (ret) return ret; }
- for (i = 0; i < dma_areas_num; i++) { - struct cma *cma = dma_areas[i]; - + for (i = 0; (cma = dma_contiguous_get_reserved_region(i)) != NULL; i++) { ret = __add_cma_heap(cma, cma_get_name(cma)); if (ret) { pr_warn("Failed to add CMA heap %s", cma_get_name(cma)); continue; } diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h index 60b63756df821d839436618f1fca2bfa3eabe075..3007c68a8ec5b85990d1938d04a2f05c1a71acdb 100644 --- a/include/linux/dma-map-ops.h +++ b/include/linux/dma-map-ops.h @@ -110,10 +110,11 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages, int count); struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp); void dma_free_contiguous(struct device *dev, struct page *page, size_t size);
void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size); +struct cma *dma_contiguous_get_reserved_region(unsigned int idx); #else /* CONFIG_DMA_CMA */ static inline struct cma *dev_get_cma_area(struct device *dev) { return NULL; } @@ -148,10 +149,14 @@ static inline void dma_free_contiguous(struct device *dev, struct page *page, __free_pages(page, get_order(size)); } static inline void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) { } +static inline struct cma *dma_contiguous_get_reserved_region(unsigned int idx) +{ + return NULL; +} #endif /* CONFIG_DMA_CMA*/
#ifdef CONFIG_DMA_DECLARE_COHERENT int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, dma_addr_t device_addr, size_t size); diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index c56004d314dc2e436cddf3b20a4ee6ce8178bee4..14bd54fb758537f01a6fe27318e7b683964e20b1 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -456,10 +456,32 @@ void dma_free_contiguous(struct device *dev, struct page *page, size_t size) #include <linux/of_reserved_mem.h>
#undef pr_fmt #define pr_fmt(fmt) fmt
+static struct cma *rmem_cma_areas[MAX_CMA_AREAS]; +static unsigned int rmem_cma_areas_num; + +static int rmem_cma_insert_area(struct cma *cma) +{ + if (rmem_cma_areas_num >= ARRAY_SIZE(rmem_cma_areas)) + return -EINVAL; + + rmem_cma_areas[rmem_cma_areas_num++] = cma; + + return 0; +} + +struct cma *dma_contiguous_get_reserved_region(unsigned int idx) +{ + if (idx >= rmem_cma_areas_num) + return NULL; + + return rmem_cma_areas[idx]; +} +EXPORT_SYMBOL_GPL(dma_contiguous_get_reserved_region); + static int rmem_cma_device_init(struct reserved_mem *rmem, struct device *dev) { dev->cma_area = rmem->priv; return 0; } @@ -504,13 +526,13 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem) rmem->priv = cma;
pr_info("Reserved memory: created CMA memory pool at %pa, size %ld MiB\n", &rmem->base, (unsigned long)rmem->size / SZ_1M);
- err = dma_heap_cma_register_heap(cma); + err = rmem_cma_insert_area(cma); if (err) - pr_warn("Couldn't register CMA heap."); + pr_warn("Couldn't store CMA reserved area.");
return 0; } RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup); #endif
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The CMA heap instantiation was initially developed by having the contiguous DMA code call into the CMA heap to create a new instance every time a reserved memory area is probed.
Turning the CMA heap into a module would create a dependency of the kernel on a module, which doesn't work.
Let's turn the logic around and do the opposite: store all the reserved memory CMA regions into the contiguous DMA code, and provide an iterator for the heap to use when it probes.
Signed-off-by: Maxime Ripard mripard@kernel.org
Reviewed-by: T.J. Mercier tjmercier@google.com
Thanks! I disabled this registration in the Android kernels where we build all dmabuf heaps as modules instead of built-in, so I can undo that if this is merged.
The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and free, respectively, its CMA buffers.
However, these functions are not exported. Since we want to turn the CMA heap into a module, let's export them both.
Signed-off-by: Maxime Ripard mripard@kernel.org --- mm/cma.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c index 94b5da468a7d719e5144d33b06bcc7619c0fbcc9..be142b473f3bd41b9c7d8ba4397f018f6993d962 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -949,10 +949,11 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, if (page) set_pages_refcounted(page, count);
return page; } +EXPORT_SYMBOL_GPL(cma_alloc);
static struct cma_memrange *find_cma_memrange(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr = NULL; @@ -1025,10 +1026,11 @@ bool cma_release(struct cma *cma, const struct page *pages,
__cma_release_frozen(cma, cmr, pages, count);
return true; } +EXPORT_SYMBOL_GPL(cma_release);
bool cma_release_frozen(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr;
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and free, respectively, its CMA buffers.
However, these functions are not exported. Since we want to turn the CMA heap into a module, let's export them both.
Signed-off-by: Maxime Ripard mripard@kernel.org
Reviewed-by: T.J. Mercier tjmercier@google.com
The CMA dma-buf heap uses the cma_get_name() function to get the name of the heap instance it's going to create.
However, this function is not exported. Since we want to turn the CMA heap into a module, let's export it.
Signed-off-by: Maxime Ripard mripard@kernel.org --- mm/cma.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/mm/cma.c b/mm/cma.c index be142b473f3bd41b9c7d8ba4397f018f6993d962..550effb9c4e01cc488b5744fe61d55a5b70a6d6c 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -50,10 +50,11 @@ unsigned long cma_get_size(const struct cma *cma)
const char *cma_get_name(const struct cma *cma) { return cma->name; } +EXPORT_SYMBOL_GPL(cma_get_name);
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma, unsigned int align_order) { if (align_order <= cma->order_per_bit)
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The CMA dma-buf heap uses the cma_get_name() function to get the name of the heap instance it's going to create.
However, this function is not exported. Since we want to turn the CMA heap into a module, let's export it.
Signed-off-by: Maxime Ripard mripard@kernel.org
Reviewed-by: T.J. Mercier tjmercier@google.com
The CMA dma-buf heap uses the dev_get_cma_area() inline function that would either return the content of device.cma_area or the content of dma_contiguous_default_area.
The latter holds a pointer to the default CMA region, and is stored in a public variable. However, that variable isn't exported which prevents to use dev_get_cma_area() in modules.
Since we want to turn the CMA heap into a module, let's export dma_contiguous_default_area to allow modules to use dev_get_cma_area().
Signed-off-by: Maxime Ripard mripard@kernel.org --- kernel/dma/contiguous.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index 14bd54fb758537f01a6fe27318e7b683964e20b1..fb64ccb99243e3cfea4890391a723130db69ee94 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -52,10 +52,11 @@ #else #define CMA_SIZE_MBYTES 0 #endif
struct cma *dma_contiguous_default_area; +EXPORT_SYMBOL_GPL(dma_contiguous_default_area);
/* * Default global CMA area size can be defined in kernel's .config. * This is useful mainly for distro maintainers to create a kernel * that works correctly for most supported systems.
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The CMA dma-buf heap uses the dev_get_cma_area() inline function that would either return the content of device.cma_area or the content of dma_contiguous_default_area.
The latter holds a pointer to the default CMA region, and is stored in a public variable. However, that variable isn't exported which prevents to use dev_get_cma_area() in modules.
Since we want to turn the CMA heap into a module, let's export dma_contiguous_default_area to allow modules to use dev_get_cma_area().
Signed-off-by: Maxime Ripard mripard@kernel.org
Reviewed-by: T.J. Mercier tjmercier@google.com
The mem_accounting kernel parameter is used by heaps to know if they should account allocations in their respective cgroup controllers.
Since we're going to allow heaps to compile as modules, we need to export that variable.
Signed-off-by: Maxime Ripard mripard@kernel.org --- drivers/dma-buf/dma-heap.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649496c0e1c6decbf263b63fa472d04..a76bf3f8b071a3d5bf39a8513f31e9e8aa16e02f 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -51,10 +51,11 @@ static DEFINE_XARRAY_ALLOC(dma_heap_minors);
bool __read_mostly mem_accounting; module_param(mem_accounting, bool, 0444); MODULE_PARM_DESC(mem_accounting, "Enable cgroup-based memory accounting for dma-buf heap allocations (default=false)."); +EXPORT_SYMBOL_NS_GPL(mem_accounting, "DMA_BUF_HEAP");
static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len, u32 fd_flags, u64 heap_flags) {
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The mem_accounting kernel parameter is used by heaps to know if they should account allocations in their respective cgroup controllers.
Since we're going to allow heaps to compile as modules, we need to export that variable.
Signed-off-by: Maxime Ripard mripard@kernel.org
Reviewed-by: T.J. Mercier tjmercier@google.com
Now that all the symbols used by the CMA heap are exported, turning the CMA heap into a module becomes pretty easy: we just need to add the usual MODULE_* macros, import the proper namespaces and change the Kconfig symbol to a tristate.
Signed-off-by: Maxime Ripard mripard@kernel.org --- drivers/dma-buf/heaps/Kconfig | 2 +- drivers/dma-buf/heaps/cma_heap.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index a5eef06c422644e8aadaf5aff2bd9a33c49c1ba3..aed0b9b4febf388376cfc41be9843980d010c4e8 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -4,11 +4,11 @@ config DMABUF_HEAPS_SYSTEM help Choose this option to enable the system dmabuf heap. The system heap is backed by pages from the buddy allocator. If in doubt, say Y.
config DMABUF_HEAPS_CMA - bool "DMA-BUF CMA Heap" + tristate "DMA-BUF CMA Heap" depends on DMABUF_HEAPS && DMA_CMA help Choose this option to enable dma-buf CMA heap. This heap is backed by the Contiguous Memory Allocator (CMA). If your system has these regions, you should say Y here. diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index f8a3d87f3ccee9630383ba28502eb40b10671cc2..7216a14262b04bb6130ddf26b7d009f7d15b03fd 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -422,5 +422,8 @@ static int __init add_cma_heaps(void)
return 0; } module_init(add_cma_heaps); MODULE_DESCRIPTION("DMA-BUF CMA Heap"); +MODULE_LICENSE("GPL"); +MODULE_IMPORT_NS("DMA_BUF"); +MODULE_IMPORT_NS("DMA_BUF_HEAP");
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
Now that all the symbols used by the CMA heap are exported, turning the CMA heap into a module becomes pretty easy: we just need to add the usual MODULE_* macros, import the proper namespaces and change the Kconfig symbol to a tristate.
Signed-off-by: Maxime Ripard mripard@kernel.org
It'd be good to add a note that heap modules can't be unloaded (unless we add more code to verify there are no live heap allocations). With that:
Reviewed-by: T.J. Mercier tjmercier@google.com
The system heap can be easily turned into a module by adding the usual MODULE_* macros, importing the proper namespaces and changing the Kconfig symbol to a tristate.
Signed-off-by: Maxime Ripard mripard@kernel.org --- drivers/dma-buf/heaps/Kconfig | 2 +- drivers/dma-buf/heaps/system_heap.c | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index aed0b9b4febf388376cfc41be9843980d010c4e8..e273fb18feca091ccd9b406e68f86c12efb339e9 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -1,7 +1,7 @@ config DMABUF_HEAPS_SYSTEM - bool "DMA-BUF System Heap" + tristate "DMA-BUF System Heap" depends on DMABUF_HEAPS help Choose this option to enable the system dmabuf heap. The system heap is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index b3650d8fd6511a4a755612cfe3a9d9fee796f80e..1957403b0f2ae5e82ab39f5945dfe82808e93964 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -442,5 +442,10 @@ static int __init system_heap_create(void) return PTR_ERR(sys_heap);
return 0; } module_init(system_heap_create); + +MODULE_DESCRIPTION("DMA-BUF System Heap"); +MODULE_LICENSE("GPL"); +MODULE_IMPORT_NS("DMA_BUF"); +MODULE_IMPORT_NS("DMA_BUF_HEAP");
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The system heap can be easily turned into a module by adding the usual MODULE_* macros, importing the proper namespaces and changing the Kconfig symbol to a tristate.
Signed-off-by: Maxime Ripard mripard@kernel.org
Same comment about a note about the module being permanent.
Reviewed-by: T.J. Mercier tjmercier@google.com
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules.
It's generally a good idea if possible, including for the already existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code.
So heaps-as-modules is common in the Android kernels, and was attempted to be upstreamed long ago: https://lore.kernel.org/lkml/20191025234834.28214-1-john.stultz@linaro.org/
And it got a fairly chilly reception, but maybe having the additional optee heap (as well as other proposed heaps) might sway folks on this now.
There is also the kref bits you might need (which Android still carries): https://lore.kernel.org/lkml/20200725032633.125006-1-john.stultz@linaro.org/
thanks -john
Hi John,
Thanks for the review
On Wed, Feb 25, 2026 at 10:51:30AM -0800, John Stultz wrote:
On Wed, Feb 25, 2026 at 8:42 AM Maxime Ripard mripard@kernel.org wrote:
The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules.
It's generally a good idea if possible, including for the already existing system and CMA heaps.
The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code.
So heaps-as-modules is common in the Android kernels, and was attempted to be upstreamed long ago: https://lore.kernel.org/lkml/20191025234834.28214-1-john.stultz@linaro.org/
And it got a fairly chilly reception, but maybe having the additional optee heap (as well as other proposed heaps) might sway folks on this now.
I didn't know that Android was using heap as modules only, but I'd say that it's even more of a reason to upstream it then.
There is also the kref bits you might need (which Android still carries): https://lore.kernel.org/lkml/20200725032633.125006-1-john.stultz@linaro.org/
I'm curious about this one though. It looks like you add refcounting, but never really get the references anywhere. What was your intent, that on every allocation the buffer would get a reference to the heap so we avoid removing a heap with allocated buffers?
Maxime
On Thu, Feb 26, 2026 at 2:18 AM Maxime Ripard mripard@kernel.org wrote:
On Wed, Feb 25, 2026 at 10:51:30AM -0800, John Stultz wrote:
So heaps-as-modules is common in the Android kernels, and was attempted to be upstreamed long ago: https://lore.kernel.org/lkml/20191025234834.28214-1-john.stultz@linaro.org/
And it got a fairly chilly reception, but maybe having the additional optee heap (as well as other proposed heaps) might sway folks on this now.
I didn't know that Android was using heap as modules only, but I'd say that it's even more of a reason to upstream it then.
There is also the kref bits you might need (which Android still carries): https://lore.kernel.org/lkml/20200725032633.125006-1-john.stultz@linaro.org/
I'm curious about this one though. It looks like you add refcounting, but never really get the references anywhere. What was your intent, that on every allocation the buffer would get a reference to the heap so we avoid removing a heap with allocated buffers?
Oh, apologies I mixed this up. You can ignore that suggestion.
In Android, once folks were familiar with thinking about dma-buf heaps, some (out of tree) drivers wanted to be able to internally allocate from a given heap (somewhat of a hold-over from the old ION drivers). So we have a convenience patch to provide that: https://android.googlesource.com/kernel/common/+/8e1ec97355ef9927e82ec18c983...
And since we return a dma_heap to the driver to allocate against: https://android.googlesource.com/kernel/common/+/fc1310ebf8fe25ea7b983400e6f...
The kref bit is to make sure we're doing proper reference counting on that shared pointer.
This ended up getting bundled together along with the heaps-as-modules changes in our out-of-tree changes, and I just confused its use here.
thanks -john
Hi John,
On Thu, Feb 26, 2026 at 10:03:21AM -0800, John Stultz wrote:
On Thu, Feb 26, 2026 at 2:18 AM Maxime Ripard mripard@kernel.org wrote:
On Wed, Feb 25, 2026 at 10:51:30AM -0800, John Stultz wrote:
So heaps-as-modules is common in the Android kernels, and was attempted to be upstreamed long ago: https://lore.kernel.org/lkml/20191025234834.28214-1-john.stultz@linaro.org/
And it got a fairly chilly reception, but maybe having the additional optee heap (as well as other proposed heaps) might sway folks on this now.
I didn't know that Android was using heap as modules only, but I'd say that it's even more of a reason to upstream it then.
There is also the kref bits you might need (which Android still carries): https://lore.kernel.org/lkml/20200725032633.125006-1-john.stultz@linaro.org/
I'm curious about this one though. It looks like you add refcounting, but never really get the references anywhere. What was your intent, that on every allocation the buffer would get a reference to the heap so we avoid removing a heap with allocated buffers?
Oh, apologies I mixed this up. You can ignore that suggestion.
In Android, once folks were familiar with thinking about dma-buf heaps, some (out of tree) drivers wanted to be able to internally allocate from a given heap (somewhat of a hold-over from the old ION drivers). So we have a convenience patch to provide that: https://android.googlesource.com/kernel/common/+/8e1ec97355ef9927e82ec18c983...
And since we return a dma_heap to the driver to allocate against: https://android.googlesource.com/kernel/common/+/fc1310ebf8fe25ea7b983400e6f...
The kref bit is to make sure we're doing proper reference counting on that shared pointer.
This ended up getting bundled together along with the heaps-as-modules changes in our out-of-tree changes, and I just confused its use here.
Understood, thanks :)
It looks like there's some people interested in doing what you described though, so we might need your patch still.
Maxime
linaro-mm-sig@lists.linaro.org
-
John Stultz -
Maxime Ripard -
T.J. Mercier