Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

7 participants
6252 discussions

[PATCH v4 0/8] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

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@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v4: - Fix compilation failure - Rework to take into account OF_RESERVED_MEM - Fix regression making the default CMA area disappear if not created through the DT - Added some documentation and comments - Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7… Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (8): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and cma_get_name() 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 | 22 +++---------- drivers/dma-buf/heaps/system_heap.c | 5 +++ include/linux/dma-buf/heaps/cma.h | 16 --------- include/linux/dma-map-ops.h | 14 ++++---- kernel/dma/contiguous.c | 66 +++++++++++++++++++++++++++++++++---- mm/cma.c | 3 ++ 8 files changed, 82 insertions(+), 49 deletions(-) --- base-commit: c081b71f11732ad2c443f170ab19c3ebe8a1a422 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 hours

Re: [PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory

by Brian Starkey

Hi, I know I'm late to the party here... Like John, I'm also not very close to this stuff any more, but I agree with the other discussions: makes sense for this to be a separate heap, and cc_shared makes sense too. I'm not clear why the heap depends on !CONFIG_HIGHMEM, but I also don't know anything about SEV/TDX. -Brian On Wed, Mar 25, 2026 at 08:23:50PM +0000, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, > run with private/encrypted memory which creates a challenge > for devices that do not support DMA to it (no TDISP support). > > For kernel-only DMA operations, swiotlb bounce buffering provides a > transparent solution by copying data through shared memory. > However, the only way to get this memory into userspace is via the DMA > API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits > the use of the memory to a single DMA device, and is incompatible with > pin_user_pages(). > > These limitations are particularly problematic for the RDMA subsystem > which makes heavy use of pin_user_pages() and expects flexible memory > usage between many different DMA devices. > > This patch series enables userspace to explicitly request shared > (decrypted) memory allocations from new dma-buf system_cc_shared heap. > Userspace can mmap this memory and pass the dma-buf fd to other > existing importers such as RDMA or DRM devices to access the > memory. The DMA API is improved to allow the dma heap exporter to DMA > map the shared memory to each importing device. > > Based on dma-mapping-for-next e7442a68cd1ee797b585f045d348781e9c0dde0d > > Jiri Pirko (2): > dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory > dma-buf: heaps: system: add system_cc_shared heap for explicitly > shared memory > > drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- > include/linux/dma-mapping.h | 10 +++ > include/trace/events/dma.h | 3 +- > kernel/dma/direct.h | 14 +++- > kernel/dma/mapping.c | 13 +++- > 5 files changed, 132 insertions(+), 11 deletions(-) > > -- > 2.51.1 >

3 hours, 30 minutes

Re: [PATCH RFC 12/18] accel/qda: Add PRIME dma-buf import support

by Christian König

On 4/2/26 10:36, Ekansh Gupta wrote: > On 3/9/2026 12:29 PM, Ekansh Gupta wrote: >> >> On 2/24/2026 2:42 PM, Christian König wrote: >>> On 2/23/26 20:09, Ekansh Gupta wrote: >>>> [Sie erhalten nicht häufig E-Mails von ekansh.gupta(a)oss.qualcomm.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Add PRIME dma-buf import support for QDA GEM buffer objects and integrate >>>> it with the existing per-process memory manager and IOMMU device model. >>>> >>>> The implementation extends qda_gem_obj to represent imported dma-bufs, >>>> including dma_buf references, attachment state, scatter-gather tables >>>> and an imported DMA address used for DSP-facing book-keeping. The >>>> qda_gem_prime_import() path handles reimports of buffers originally >>>> exported by QDA as well as imports of external dma-bufs, attaching them >>>> to the assigned IOMMU device >>> That is usually an absolutely clear NO-GO for DMA-bufs. Where exactly in the code is that? >> dma_buf_attach* to comute-cb iommu devices are critical for DSPs to access the buffer. >> This is needed if the buffer is exported by anyone other than QDA(say system heap). If this is not >> the correct way, what should be the right way here? On the current fastrpc driver also, >> the DMABUF is getting attached with iommu device[1] due to the same requirement. >> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/dr… > > Hi Christian, > > Do you have any suggestions for the shared requirements? Well I don't fully understand what you are trying to do with the iommu. Usually it is the job of the exporter to provide the importer with DMA addresses which are valid for its device structure, that includes IOMMU mapping. Can you iterate what exactly this iommu group is and why you have to attach the imported buffers to it, how that attachment works and how lifetime is managed? Regards, Christian. > > I'm reworking on the next version and currently I don't see any other way > to handle dma_buf_attach* cases. > > //Ekansh > >>>> and mapping them through the memory manager >>>> for DSP access. The GEM free path is updated to unmap and detach >>>> imported buffers while preserving the existing behaviour for locally >>>> allocated memory. >>>> >>>> The PRIME fd-to-handle path is implemented in qda_prime_fd_to_handle(), >>>> which records the calling drm_file in a driver-private import context >>>> before invoking the core DRM helpers. The GEM import callback retrieves >>>> this context to ensure that an IOMMU device is assigned to the process >>>> and that imported buffers follow the same per-process IOMMU selection >>>> rules as natively allocated GEM objects. >>>> >>>> This patch prepares the driver for interoperable buffer sharing between >>>> QDA and other dma-buf capable subsystems while keeping IOMMU mapping and >>>> lifetime handling consistent with the existing GEM allocation flow. >>>> >>>> Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> >>> ... >>> >>>> @@ -15,23 +16,29 @@ static int validate_gem_obj_for_mmap(struct qda_gem_obj *qda_gem_obj) >>>> qda_err(NULL, "Invalid GEM object size\n"); >>>> return -EINVAL; >>>> } >>>> - if (!qda_gem_obj->iommu_dev || !qda_gem_obj->iommu_dev->dev) { >>>> - qda_err(NULL, "Allocated buffer missing IOMMU device\n"); >>>> - return -EINVAL; >>>> - } >>>> - if (!qda_gem_obj->iommu_dev->dev) { >>>> - qda_err(NULL, "Allocated buffer missing IOMMU device\n"); >>>> - return -EINVAL; >>>> - } >>>> - if (!qda_gem_obj->virt) { >>>> - qda_err(NULL, "Allocated buffer missing virtual address\n"); >>>> - return -EINVAL; >>>> - } >>>> - if (qda_gem_obj->dma_addr == 0) { >>>> - qda_err(NULL, "Allocated buffer missing DMA address\n"); >>>> - return -EINVAL; >>>> + if (qda_gem_obj->is_imported) { >>> Absolutely clear NAK to that. Imported buffers *can't* be mmaped through the importer! >>> >>> Userspace needs to mmap() them through the exporter. >>> >>> If you absolutely have to map them through the importer for uAPI backward compatibility then there is dma_buf_mmap() for that, but this is clearly not the case here. >>> >>> ... >> Okay, the requirement is slightly different here. Any buffer which is not allocated using the >> QDA GEM interface needs to be attached to the iommu device for that particular process to >> enable DSP for the access. I should not call it `mmap` instead it should be called importing the >> buffer to a particular iommu context bank. With this definition, is it fine to keep it this way? Or >> should the dma_buf_attach* calls be moved to some other place? >>>> +static int qda_memory_manager_map_imported(struct qda_memory_manager *mem_mgr, >>>> + struct qda_gem_obj *gem_obj, >>>> + struct qda_iommu_device *iommu_dev) >>>> +{ >>>> + struct scatterlist *sg; >>>> + dma_addr_t dma_addr; >>>> + int ret = 0; >>>> + >>>> + if (!gem_obj->is_imported || !gem_obj->sgt || !iommu_dev) { >>>> + qda_err(NULL, "Invalid parameters for imported buffer mapping\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + gem_obj->iommu_dev = iommu_dev; >>>> + >>>> + sg = gem_obj->sgt->sgl; >>>> + if (sg) { >>>> + dma_addr = sg_dma_address(sg); >>>> + dma_addr += ((u64)iommu_dev->sid << 32); >>>> + >>>> + gem_obj->imported_dma_addr = dma_addr; >>> Well that looks like you are only using the first DMA address from the imported sgt. What about the others? >> I might have a proper appach for this now, will update in the next spin. >>> Regards, >>> Christian. >

6 hours, 41 minutes

Re: [PATCH v3 5/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Marek Szyprowski

On 16.03.2026 13:08, Maxime Ripard wrote: > On Wed, Mar 11, 2026 at 08:18:28AM -0500, Andrew Davis wrote: >> On 3/11/26 5:19 AM, Albert Esteve wrote: >>> On Tue, Mar 10, 2026 at 4:34 PM Andrew Davis <afd(a)ti.com> wrote: >>>> On 3/6/26 4:36 AM, Albert Esteve wrote: >>>>> Expose DT coherent reserved-memory pools ("shared-dma-pool" >>>>> without "reusable") as dma-buf heaps, creating one heap per >>>>> region so userspace can allocate from the exact device-local >>>>> pool intended for coherent DMA. >>>>> >>>>> This is a missing backend in the long-term effort to steer >>>>> userspace buffer allocations (DRM, v4l2, dma-buf heaps) >>>>> through heaps for clearer cgroup accounting. CMA and system >>>>> heaps already exist; non-reusable coherent reserved memory >>>>> did not. >>>>> >>>>> The heap binds the heap device to each memory region so >>>>> coherent allocations use the correct dev->dma_mem, and >>>>> it defers registration until module_init when normal >>>>> allocators are available. >>>>> >>>>> Signed-off-by: Albert Esteve <aesteve(a)redhat.com> >>>>> --- >>>>> drivers/dma-buf/heaps/Kconfig | 9 + >>>>> drivers/dma-buf/heaps/Makefile | 1 + >>>>> drivers/dma-buf/heaps/coherent_heap.c | 414 ++++++++++++++++++++++++++++++++++ >>>>> 3 files changed, 424 insertions(+) >>>>> >>>>> (...) >>>> You are doing this DMA allocation using a non-DMA pseudo-device (heap_dev). >>>> This is why you need to do that dma_coerce_mask_and_coherent(64) nonsense, you >>>> are doing a DMA alloc for the CPU itself. This might still work, but only if >>>> dma_map_sgtable() can handle swiotlb/iommu for all attaching devices at map >>>> time. >>> The concern is valid. We're allocating via a synthetic device, which >>> ties the allocation to that device's DMA domain. I looked deeper into >>> this trying to address the concern. >>> >>> The approach works because dma_map_sgtable() handles both >>> dma_map_direct and use_dma_iommu cases in __dma_map_sg_attrs(). For >>> each physical address in the sg_table (extracted via sg_phys()), it >>> creates device-specific DMA mappings: >>> - For direct mapping: it checks if the address is directly accessible >>> (dma_capable()), and if not, it falls back to swiotlb. >>> - For IOMMU: it creates mappings that allow the device to access >>> physical addresses. >>> >>> This means every attached device gets its own device-specific DMA >>> mapping, properly handling cases where the physical addresses are >>> inaccessible or have DMA constraints. >>> >> While this means it might still "work" it won't always be ideal. Take >> the case where the consuming device(s) have a 32bit address restriction, >> if the allocation was done using the real devices then the backing buffer >> itself would be allocated in <32bit mem. Whereas here the allocation >> could end up in >32bit mem, as the CPU/synthetic device supports that. >> Then each mapping device would instead get a bounce buffer. >> >> (this example might not be great as we usually know the address of >> carveout/reserved memory regions, but substitute in whatever restriction >> makes more sense) >> >> These non-reusable carveouts tend to be made for some specific device, and >> they are made specifically because that device has some memory restriction. >> So we might run into the situation above more than one would expect. >> >> Not a blocker here, but just something worth thinking on. > As I detailed in the previous version [1] the main idea behind that work > is to allow to get rid of dma_alloc_attrs for framework and drivers to > allocate from the heaps instead. > > Robin was saying he wasn't comfortable with exposing this heap to > userspace, and we're saying here that maybe this might not always work > anyway (or at least that we couldn't test it fully). > > Maybe the best thing is to defer this series until we are at a point > where we can start enabling the "heap allocations" in frameworks then? > Hopefully we will have hardware to test it with by then, and we might > not even need to expose it to userspace at all but only to the kernel. > > What do you think? IMHO a good idea. Maybe in-kernel heap for the coherent allocations will be just enough. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

8 hours, 40 minutes

Re: [PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory

by Sumit Semwal

Hello Jiri, On Thu, 26 Mar 2026 at 00:53, Jiri Pirko <jiri(a)resnulli.us> wrote: > > From: Jiri Pirko <jiri(a)nvidia.com> > > Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, > run with private/encrypted memory which creates a challenge > for devices that do not support DMA to it (no TDISP support). > > For kernel-only DMA operations, swiotlb bounce buffering provides a > transparent solution by copying data through shared memory. > However, the only way to get this memory into userspace is via the DMA > API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits > the use of the memory to a single DMA device, and is incompatible with > pin_user_pages(). > > These limitations are particularly problematic for the RDMA subsystem > which makes heavy use of pin_user_pages() and expects flexible memory > usage between many different DMA devices. > > This patch series enables userspace to explicitly request shared > (decrypted) memory allocations from new dma-buf system_cc_shared heap. > Userspace can mmap this memory and pass the dma-buf fd to other > existing importers such as RDMA or DRM devices to access the > memory. The DMA API is improved to allow the dma heap exporter to DMA > map the shared memory to each importing device. Thank you for the patch series, it looks good to me. Marek, if you are ok, please could you take it through your tree, with my Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org> Best, Sumit. > > Based on dma-mapping-for-next e7442a68cd1ee797b585f045d348781e9c0dde0d > > Jiri Pirko (2): > dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory > dma-buf: heaps: system: add system_cc_shared heap for explicitly > shared memory > > drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- > include/linux/dma-mapping.h | 10 +++ > include/trace/events/dma.h | 3 +- > kernel/dma/direct.h | 14 +++- > kernel/dma/mapping.c | 13 +++- > 5 files changed, 132 insertions(+), 11 deletions(-) > > -- > 2.51.1 >

9 hours, 57 minutes

Can I Safely Explore Leh Ladakh?

by Emma Stone

I often get this question in my mind when I think about visiting the mountains — is Leh Ladakh safe for visitors like me? The place looks absolutely beautiful in photos, with huge mountains, quiet monasteries, and those long scenic roads. But at the same time, I always wonder about the altitude, weather, and road conditions. Since it’s a high-altitude region, I feel it’s important to understand how the body reacts there and how much time I should give myself to adjust. From what I’ve learned so far, many travelers visit every year and most of them have a wonderful experience. Still, I always prefer to read carefully and plan things before going anywhere new. I like checking routes, the best months to visit, and what kind of preparations I should make. That’s why I started looking through a Leh Ladakh travel guide, because it answers many of the small questions I have in my mind. I also feel safer knowing that tourism is common there and local people are welcoming to visitors. So maybe the real question for me is not just safety, but how well I plan my trip. With the right preparation, the journey can be amazing. 🏔️✨ More details: https://www.indiahighlight.com/destination/leh-ladakh 📧 emmastone(a)yzcalo.com 📞 19707840507

1 day, 10 hours

Re: [PATCH v5 2/2] dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory

by Jason Gunthorpe

On Wed, Mar 25, 2026 at 08:23:52PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Add a new "system_cc_shared" dma-buf heap to allow userspace to > allocate shared (decrypted) memory for confidential computing (CoCo) > VMs. > > On CoCo VMs, guest memory is private by default. The hardware uses an > encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on > Intel TDX) to control whether a given memory access is private or > shared. The kernel's direct map is set up as private, > so pages returned by alloc_pages() are private in the direct map > by default. To make this memory usable for devices that do not support > DMA to private memory (no TDISP support), it has to be explicitly > shared. A couple of things are needed to properly handle > shared memory for the dma-buf use case: > > - set_memory_decrypted() on the direct map after allocation: > Besides clearing the encryption bit in the direct map PTEs, this > also notifies the hypervisor about the page state change. On free, > the inverse set_memory_encrypted() must be called before returning > pages to the allocator. If re-encryption fails, pages > are intentionally leaked to prevent shared memory from being > reused as private. > > - pgprot_decrypted() for userspace and kernel virtual mappings: > Any new mapping of the shared pages, be it to userspace via > mmap or to kernel vmalloc space via vmap, creates PTEs independent > of the direct map. These must also have the encryption bit cleared, > otherwise accesses through them would see encrypted (garbage) data. > > - DMA_ATTR_CC_SHARED for DMA mapping: > Since the pages are already shared, the DMA API needs to be > informed via DMA_ATTR_CC_SHARED so it can map them correctly > as unencrypted for device access. > > On non-CoCo VMs, the system_cc_shared heap is not registered > to prevent misuse by userspace that does not understand > the security implications of explicitly shared memory. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v4->v5: > - bools renamed: s/decrypted/cc_decrypted/ > - other renames: s/decrypted/decrypted/ - this included name of the heap > v2->v3: > - removed couple of leftovers from headers > v1->v2: > - fixed build errors on s390 by including mem_encrypt.h > - converted system heap flag implementation to a separate heap > --- > drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- > 1 file changed, 98 insertions(+), 5 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

1 day, 10 hours

Re: [PATCH v5 1/2] dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory

by Jason Gunthorpe

On Wed, Mar 25, 2026 at 08:23:51PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri(a)nvidia.com> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > shared memory on behalf of the device. > > When a caller has already arranged for the memory to be shared > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_SHARED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. > > Signed-off-by: Jiri Pirko <jiri(a)nvidia.com> > --- > v4->v5: > - rebased on top od dma-mapping-for-next > - s/decrypted/shared/ > v3->v4: > - added some sanity checks to dma_map_phys and dma_unmap_phys > - enhanced documentation of DMA_ATTR_CC_DECRYPTED attr > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 10 ++++++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > kernel/dma/mapping.c | 13 +++++++++++-- > 4 files changed, 34 insertions(+), 6 deletions(-) Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

2 days

Re: [PATCH] dma-fence: Move signalling tracepoint to before ops detach

by Christian König

On 3/30/26 15:36, Tvrtko Ursulin wrote: > Move the signalling tracepoint to before fence->ops are reset otherwise > tracepoint will dereference a null pointer. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Cc: Christian König <christian.koenig(a)amd.com> > Cc: Philipp Stanner <phasta(a)kernel.org> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: linux-media(a)vger.kernel.org > Cc: linaro-mm-sig(a)lists.linaro.org Good catch. I just silently assumed that the fence is not signaled when we traced signaling. Going to take another look since there might be more problems, but for now: Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 1826ba73094c..1c1eaecaf1b0 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > &fence->flags))) > return; > > + trace_dma_fence_signaled(fence); > + > /* > * When neither a release nor a wait operation is specified set the ops > * pointer to NULL to allow the fence structure to become independent > @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > > fence->timestamp = timestamp; > set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); > - trace_dma_fence_signaled(fence); > > list_for_each_entry_safe(cur, tmp, &cb_list, node) { > INIT_LIST_HEAD(&cur->node);

2 days, 6 hours

[PATCH v2] dma/contiguous: Fix broken build

by Maxime Ripard

Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") didn't remove one last call to dma_heap_cma_register_heap() that it removed, thus breaking the build. That last call is in dma_contiguous_reserve(), to handle the registration of the default CMA region heap instance. The default CMA region instance is already somewhat handled by retrieving it through the dev_get_cma_area() call in the CMA heap driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"), we will create two heap instances for the CMA default region. The first one is always called "default_cma_region", and is the one handled by the call to dev_get_cma_area() mentioned earlier. The second one is the name it used to have prior to that last commit for backward compatibility. In the case where the default CMA region is defined in the DT, then that region is registered through rmem_cma_setup() and that region is added to the list of CMA regions to create a CMA heap instance for. In the case where the default CMA region is not defined in the DT though used to be the case covered by the now removed dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only remove the call to dma_heap_cma_register_heap(), then the legacy name of the CMA heap will not be registered anymore. We thus need to replace that call with a call to rmem_cma_insert_area() to make sure we queue this instance, if created, to create a heap instance. Once that call to dma_heap_cma_register_heap() replaced, we can also remove the now unused function definition, its now empty header, and all includes of this header. Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") Reported-by: Mark Brown <broonie(a)kernel.org> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Fix creation of the CMA heap instance with the legacy name when not declared in the DT. - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@kernel.o… --- drivers/dma-buf/heaps/cma_heap.c | 1 - include/linux/dma-buf/heaps/cma.h | 16 ---------------- kernel/dma/contiguous.c | 14 +++++++++++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,11 +12,10 @@ #define pr_fmt(fmt) "cma_heap: " fmt #include <linux/cma.h> #include <linux/dma-buf.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-heap.h> #include <linux/dma-map-ops.h> #include <linux/err.h> #include <linux/highmem.h> #include <linux/io.h> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h deleted file mode 100644 index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000 --- a/include/linux/dma-buf/heaps/cma.h +++ /dev/null @@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef DMA_BUF_HEAP_CMA_H_ -#define DMA_BUF_HEAP_CMA_H_ - -struct cma; - -#ifdef CONFIG_DMABUF_HEAPS_CMA -int dma_heap_cma_register_heap(struct cma *cma); -#else -static inline int dma_heap_cma_register_heap(struct cma *cma) -{ - return 0; -} -#endif // CONFIG_DMABUF_HEAPS_CMA - -#endif // DMA_BUF_HEAP_CMA_H_ diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,11 +40,10 @@ #include <asm/page.h> #include <linux/memblock.h> #include <linux/err.h> #include <linux/sizes.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-map-ops.h> #include <linux/cma.h> #include <linux/nospec.h> #ifdef CONFIG_CMA_SIZE_MBYTES @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void) static inline void __init dma_numa_cma_reserve(void) { } #endif +#ifdef CONFIG_OF_RESERVED_MEM +static int rmem_cma_insert_area(struct cma *cma); +#else +static inline int rmem_cma_insert_area(struct cma *cma) +{ + return 0; +} +#endif + /** * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling * @limit: End address of the reserved memory (optional, 0 for any). * * This function reserves memory from early allocator. It should be @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit) &dma_contiguous_default_area, fixed); if (ret) return; - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); + ret = rmem_cma_insert_area(dma_contiguous_default_area); if (ret) - pr_warn("Couldn't register default CMA heap."); + pr_warn("Couldn't queue default CMA region for heap creation."); } } void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --- base-commit: 6c683d5b1903a14e362c9f1628ce9fe61eac35e7 change-id: 20260330-dma-build-fix-706a4feb0e0f Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 days, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig