On Thu, Feb 26, 2026 at 2:18 AM Maxime Ripard <[email protected]> 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/[email protected]/ > > > > 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/[email protected]/ > > 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
