Re: [PATCH] dmaengine: ti: k3-udma: Use common error handling code in udma_prep_slave_sg_pkt()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The error handling label `free_hwdesc` is inappropriately placed inside an unrelated conditional block, creating non-linear control flow.
--

commit 8ea86eb1521c2e6195625764d7c02223ede1fd79
Author: Markus Elfring <elfring@users.sourceforge.net>

dmaengine: ti: k3-udma: Use common error handling code in udma_prep_slave_sg_pkt()

This commit introduces a new goto label to reuse error handling code when
descriptor allocation fails. The cleanup logic is now consolidated to avoid
duplication.

> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
> index c964ebfcf3b68..b56ee3ca848ef 100644
> --- a/drivers/dma/ti/k3-udma.c
> +++ b/drivers/dma/ti/k3-udma.c

[ ... ]

> @@ -3309,6 +3306,7 @@ udma_prep_slave_sg_pkt(struct udma_chan *uc, struct scatterlist *sgl,
>  		dev_err(uc->ud->dev,
>  			"%s: Transfer size %u is over the supported 4M range\n",
>  			__func__, d->residue);
> +free_hwdesc:

[Severity: Low]
Does placing this error handling label inside the unrelated residue bounds
check block create confusing control flow?

Jumping into the middle of the if (d->residue >= SZ_4M) block works currently,
but could it silently break the descriptor allocation error path if this
bounds check block is ever modified or removed in the future?

>  		udma_free_hwdesc(uc, d);
>  		kfree(d);
>  		return NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/225b97d8-425c-46ea-bee2-df73753bca8c@web.de?part=1