[PATCH v3] crypto/amlogic: Use devm APIs for clock management

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] crypto: amlogic: memory leak and UAF on probe error path
- [Low] crypto: amlogic: build failure due to misspelled meson_allocate_chainlist
--

commit 798e78c31473ca6be8ca9d38739f43b6653307b6
Author: Mohamad Raizudeen <raizudeen.kerneldev at gmail.com>

crypto/amlogic: Use devm APIs for clock management

This commit converts the driver to use devm_clk_get_enabled instead of
manually getting and enabling the core clock. This change allows the removal
of manual cleanup code in the error paths and simplifies the probe function.

Closes: https://lore.kernel.org/oe-kbuild-all/202608310329.QgxCCMs1-lkp@intel.com/

> diff --git a/drivers/crypto/amlogic/amlogic-gxl-core.c b/drivers/crypto/amlogic/amlogic-gxl-core.c
> index 169c6eeb51e51..d2d23a443c53f 100644
> --- a/drivers/crypto/amlogic/amlogic-gxl-core.c
> +++ b/drivers/crypto/amlogic/amlogic-gxl-core.c
[ ... ]
> @@ -243,13 +243,17 @@ static int meson_crypto_probe(struct platform_device *pdev)
>  	if (IS_ERR(mc->base))
>  		return PTR_ERR(mc->base);
>  
> -	mc->busclk = devm_clk_get(&pdev->dev, "blkmv");
> +	mc->busclk = devm_clk_get_enabled(&pdev->dev, "blkmv");
>  	if (IS_ERR(mc->busclk)) {
>  		err = PTR_ERR(mc->busclk);
> -		dev_err(&pdev->dev, "Cannot get core clock err=%d\n", err);
> +		dev_err(&pdev->dev, "Cannot get/enable core clock err=%d\n", err);
>  		return err;
>  	}
>  
> +	err = meson_allocate_chainlist(mc);
               ^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Low]
Is there a typo in the function name meson_allocate_chainlist?

> +	if (err)
> +		return err;
> +
>  	for (i = 0; i < MAXFLOW; i++) {
>  		mc->irqs[i] = platform_get_irq(pdev, i);
>  		if (mc->irqs[i] < 0)
>  			return mc->irqs[i];

[Severity: High]
Since the allocation of chanlist was moved before this loop, if
platform_get_irq fails, does returning directly here bypass the cleanup of
resources allocated by meson_allocate_chanlist?

If this cleanup is bypassed, could it cause a use-after-free when orphaned
kthreads attempt to access the devm-managed engine structures after they are
freed?

>  
>  		err = devm_request_irq(&pdev->dev, mc->irqs[i], meson_irq_handler, 0,
>  				       "gxl-crypto", mc);
>  		if (err < 0)
>  			return err;

[Severity: High]
Similarly, if devm_request_irq fails, does returning directly here bypass
cleanup, leaking DMA coherent memory and leaving crypto_engine kthreads
running?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916154941.7254-1-raizudeen.kerneldev@gmail.com?part=1