linux.git/include/linux/dma-map-ops.h, branch v7.3-rc2

dma-pool: track decrypted atomic pools and select them via attrs

2026-07-31T06:40:58+00:00

Teach the atomic DMA pool code to distinguish between encrypted and
unencrypted pools, and make pool allocation select the matching pool based
on DMA attributes.

Introduce a dma_gen_pool wrapper that records whether a pool is
unencrypted, initialize that state when the atomic pools are created, and
use it when expanding and resizing the pools. Update dma_alloc_from_pool()
to take attrs and skip pools whose encrypted state does not match
__DMA_ATTR_ALLOC_CC_SHARED. Update dma_free_from_pool() accordingly.

Also pass __DMA_ATTR_ALLOC_CC_SHARED from the swiotlb atomic allocation
path so decrypted swiotlb allocations are taken from the correct atomic
pool.

Tested-by: Jiri Pirko 
Tested-by: Michael Kelley 
Tested-by: Mostafa Saleh 
Reviewed-by: Mostafa Saleh 
Signed-off-by: Aneesh Kumar K.V (Arm) 
Link: https://lore.kernel.org/r/20260717180442.110954-12-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski

dma: free atomic pool pages by physical address

2026-07-31T06:40:58+00:00

dma_direct_alloc_pages() may satisfy atomic allocations from the coherent
atomic pools. The pool allocation is keyed by the virtual address stored in
the gen_pool, but the pages API returns only the backing struct page.

On architectures with CONFIG_DMA_DIRECT_REMAP, atomic pool chunks are added
to the gen_pool using their remapped virtual address.
dma_direct_free_pages() reconstructs a linear-map address with
page_address(page) and passes that to dma_free_from_pool(). That address
does not match the gen_pool virtual range, so the pool lookup can fail and
the code can fall through to freeing a pool-owned page through the normal
page allocator path.

Add a page-based pool free helper that looks up the owning pool chunk by
physical address, translates it back to the gen_pool virtual address, and
frees that address to the pool. Use it from dma_direct_free_pages() while
keeping the existing virtual-address helper for coherent allocation frees.

Tested-by: Michael Kelley 
Tested-by: Mostafa Saleh 
Signed-off-by: Aneesh Kumar K.V (Arm) 
Link: https://lore.kernel.org/r/20260717180442.110954-5-aneesh.kumar@kernel.org
Signed-off-by: Marek Szyprowski

driver core: Replace dev->dma_coherent with dev_dma_coherent()

2026-04-26T21:43:58+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "dma_coherent" over to the "flags"
field so modifications are safe.

Cc: Christoph Hellwig 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Acked-by: Vinod Koul 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260406162231.v5.7.If839f6dde98979fce177f70c6c74689a1904ee76@changeid
[ Since all DEV_FLAG_DMA_COHERENT accessors are exposed unconditionally,
  also drop the CONFIG guards around dev_assign_dma_coherent() in
  device_initialize() to ensure a correct default value. - Danilo ]
Signed-off-by: Danilo Krummrich

driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()

2026-04-26T21:38:57+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "dma_skip_sync" over to the "flags"
field so modifications are safe.

Cc: Alexander Lobakin 
Cc: Eric Dumazet 
Cc: Christoph Hellwig 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Signed-off-by: Douglas Anderson 
Link: https://patch.msgid.link/20260406162231.v5.4.Icf072aa4184dd86a88fa8ca195b09d1651984000@changeid
Signed-off-by: Danilo Krummrich

Merge branch 'dma-contig-for-7.1-modules-prep-v4' into dma-mapping-for-next

2026-03-31T12:52:03+00:00

Signed-off-by: Marek Szyprowski

dma: contiguous: Make dma_contiguous_default_area static

2026-03-31T11:27:20+00:00

Now that dev_get_cma_area() is no longer inline, we don't have any user
of dma_contiguous_default_area() outside of contiguous.c so we can make
it static.

Signed-off-by: Maxime Ripard 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-3-e18fda504419@kernel.org

dma: contiguous: Make dev_get_cma_area() a proper function

2026-03-31T11:27:20+00:00

As we try to enable dma-buf heaps, and the CMA one in particular, to
compile as modules, we need to export dev_get_cma_area(). It's currently
implemented as an inline function that returns either the content of
device->cma_area or dma_contiguous_default_area.

Thus, it means we need to export dma_contiguous_default_area, which
isn't really something we want any module to have access to.

Instead, let's make dev_get_cma_area() a proper function we will be able
to export so we can avoid exporting dma_contiguous_default_area.

Signed-off-by: Maxime Ripard 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-2-e18fda504419@kernel.org

dma: contiguous: Turn heap registration logic around

2026-03-31T11:27:20+00:00

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 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-1-e18fda504419@kernel.org

Merge branch 'dt-reserved-mem-cleanups' into dma-mapping-for-next

2026-03-27T07:48:51+00:00

Signed-off-by: Marek Szyprowski

of: reserved_mem: replace CMA quirks by generic methods

2026-03-26T19:12:02+00:00

Add optional reserved memory callbacks to perform region verification and
early fixup, then move all CMA related code in of_reserved_mem.c to them.

Signed-off-by: Marek Szyprowski 
Link: https://patch.msgid.link/20260325090023.3175348-5-m.szyprowski@samsung.com
Signed-off-by: Rob Herring (Arm)