Re: [PATCH 0/7] dma-buf: heaps: Turn heaps into modules

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]