Re: [PATCH v2 0/8] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Apr 20, 2026 at 11:44:07AM +0530, Aneesh Kumar K.V (Arm) wrote:
> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
> are handled consistently.
> 
> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
> shared/decrypted buffer handling. This series consolidates the
> force_dma_unencrypted() checks in the top-level functions and ensures
> that the remaining DMA interfaces use DMA attributes to make the correct
> decisions.
> 
> The series:
> - moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
> - propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free
>   paths,
> - teaches the atomic DMA pools to track encrypted versus decrypted
>   state,
> - tracks swiotlb pool encryption state and enforces strict pool
>   selection,
> - centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
>   DMA attributes,
> - makes dma_direct_map_phys() choose the DMA address encoding from
>   attrs, and
> - uses the selected swiotlb pool state to derive the returned DMA
>   address.

I think this is very reasonable looking.

Jason