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@linaro.org/

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,
-- 
Maxime Ripard <mripard@kernel.org>

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/+/8e1ec97355ef9927e82ec18c98312bdcd80bf289%5E%21/

And since we return a dma_heap to the driver to allocate against:
  https://android.googlesource.com/kernel/common/+/fc1310ebf8fe25ea7b983400e6fa41f5a6d11966%5E%21/

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/+/8e1ec97355ef9927e82ec18c98312bdcd80bf289%5E%21/
> 
> And since we return a dma_heap to the driver to allocate against:
>   https://android.googlesource.com/kernel/common/+/fc1310ebf8fe25ea7b983400e6fa41f5a6d11966%5E%21/
> 
> 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