Re: [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] PM runtime usage counter and hardware clocks leak in `zynqmp_dma_probe` error path.
--

--- Patch [4]: [PATCH 4/6] dmaengine: zynqmp_dma: Fix minor whitespace ---
commit 990948221cda48a26b5380f5bdf1dcf6dfa5ba05
Author: Golla Nagendra <[email protected]>

dmaengine: zynqmp_dma: Fix minor whitespace

This commit fixes minor whitespace formatting in zynqmp_dma_chan_probe().

> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c

[ ... ]

> @@ -959,6 +959,7 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
>  
>  	dma_cookie_init(&chan->common);
>  	chan->common.device = &zdev->common;
> +
>  	zynqmp_dma_init(chan);
>  	ret = platform_get_irq(pdev, 0);
>  	if (ret < 0)

[Severity: High]
This isn't a bug introduced by this patch, but if platform_get_irq() fails
here and returns an error like -EPROBE_DEFER, does the caller leak the PM
runtime usage count and hardware clocks?

Looking at the caller zynqmp_dma_probe(), the error path seems to miss
dropping the usage count (e.g., via pm_runtime_put_noidle() or
pm_runtime_put_sync()):

zynqmp_dma_probe() {
        ...
        ret = zynqmp_dma_chan_probe(zdev, pdev);
        if (ret)
                goto err_disable_pm;
        ...
err_disable_pm:
        if (!pm_runtime_enabled(zdev->dev))
                zynqmp_dma_runtime_suspend(zdev->dev);
        pm_runtime_disable(zdev->dev);
        return ret;
}

Since probe deferral is a common event during system boot, could repeated
deferrals continually leak the PM usage count and permanently leave the DMA
hardware clocks enabled, preventing the device from being runtime suspended?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4