Re: [PATCH v4 9/9] crypto: atmel: Use dmaengine_prep_config_single() API

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The commit message incorrectly references `dmaengine_prep_config_single()` instead of `dmaengine_prep_config_sg()`.
- [Medium] DMA configuration errors are masked as Out-Of-Memory (-ENOMEM) errors, contradicting the 'No functional change' claim.
--

commit 321a15c31b7c3672b47256b90654c736d1c61477
Author: Frank Li <Frank.Li@nxp.com>

crypto: atmel: Use dmaengine_prep_config_single() API

This commit updates the atmel-aes driver to use a combined DMA preparation API
instead of calling configuration and preparation functions separately. The
commit message claims there is no functional change.

> crypto: atmel: Use dmaengine_prep_config_single() API
> 
> Using new API dmaengine_prep_config_single() to simple code.

This isn't a bug, but the commit message references
dmaengine_prep_config_single() here and in the subject line, while the actual
code uses dmaengine_prep_config_sg().

> diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
> index b393689400b4c..d890b5a277b9c 100644
> --- a/drivers/crypto/atmel-aes.c
> +++ b/drivers/crypto/atmel-aes.c

[ ... ]

> @@ -820,12 +819,9 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
>  		return -EINVAL;
>  	}
>  
> -	err = dmaengine_slave_config(dma->chan, &config);
> -	if (err)
> -		return err;
> -
> -	desc = dmaengine_prep_slave_sg(dma->chan, dma->sg, dma->sg_len, dir,
> -				       DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> +	desc = dmaengine_prep_config_sg(dma->chan, dma->sg, dma->sg_len, dir,
> +					DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
> +					&config);
>  	if (!desc)
>  		return -ENOMEM;

The commit message mentions "No functional change", but does this alter the
error code propagated on configuration failures?

Previously, if dmaengine_slave_config() failed, its specific error code was
returned directly to the caller. Now, dmaengine_prep_config_sg() internally
calls dmaengine_slave_config() and returns NULL on failure, which is
unconditionally mapped to -ENOMEM here.

Could this lead to DMA configuration errors being incorrectly reported as
out-of-memory errors to the upper crypto layers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506-dma_prep_config-v4-0-85b3d22babff@nxp.com?part=9