Re: [RFC PATCH 2/7] dma-direct: use DMA_ATTR_CC_DECRYPTED in alloc/free paths

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Apr 17, 2026 at 02:28:55PM +0530, Aneesh Kumar K.V (Arm) wrote:
> Propagate force_dma_unencrypted() into DMA_ATTR_CC_DECRYPTED in the
> dma-direct allocation path and use the attribute to drive the related
> decisions.
> 
> This updates dma_direct_alloc(), dma_direct_free(), and
> dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
> 
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
>  kernel/dma/direct.c | 34 ++++++++++++++++++++++++++--------
>  1 file changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index c2a43e4ef902..3932033f4d8c 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -201,16 +201,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>  		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>  {
>  	bool remap = false, set_uncached = false;
> -	bool mark_mem_decrypt = true;
> +	bool mark_mem_decrypt = !!(attrs & DMA_ATTR_CC_DECRYPTED);
>  	struct page *page;

This is changing the API, I think it should not be hidden in a patch
like this, also not sure it even makes sense..

DMA_ATTR_CC_DECRYPTED only says the address passed to mapping is
decrypted. It is like DMA_ATTR_MMIO in this regard.

Passing it to dma_alloc_attrs() is currently invalid, and I think it
should remain invalid, or at least this new behavior introduced in its
own patch deliberately.

Meaning, if you call dma_direct_alloc() force_dma_decrypted decides
what setting DMA_ATTR_CC_DECRYPTED takes and it is EOPNOTSUPP if the
user passes it in.

Jason