Re: [PATCH v17 14/14] crypto: qce - Communicate the base physical address to the dmaengine

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Passing 0 as the length parameter to `dmaengine_desc_attach_metadata()` bypasses size validation.
--

commit 1f893f890dfe69aa8cb0e7aec2e87e8d24b5cdc6
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

crypto: qce - Communicate the base physical address to the dmaengine

This commit fills out and attaches the BAM descriptor metadata to the DMA
descriptor. This provides the BAM DMA engine with the scratchpad address
for dummy writes related to pipe locking.

> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index b66e6386fccda..97b0f02c2b4d2 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c

[ ... ]

> @@ -63,6 +68,10 @@ int qce_submit_cmd_desc(struct qce_device *qce)
>  		goto err_unmap_sg;
>  	}
>  
> +	ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);

Should this call pass sizeof(meta) instead of 0 for the length parameter?

The generic DMA engine API dmaengine_desc_attach_metadata() expects the
length argument to specify the size of the metadata payload being attached.
While the underlying BAM DMA provider might not currently validate the length
parameter, passing 0 bypasses this API contract.

If size validation is enforced in the future by the generic DMA framework or
the underlying driver, this could cause the call to unconditionally fail.

> +	if (ret)
> +		goto err_unmap_sg;
> +
>  	qce_desc->dma_desc = dma_desc;
>  	cookie = dmaengine_submit(qce_desc->dma_desc);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com?part=14