Re: [PATCH 07/10] dmaengine: fsldma: convert channel ioremap to devm_of_iomap

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `irq_dispose_mapping()` for per-channel IRQs causes a mapping leak when a channel is removed.
- [High] Failure to propagate `-EPROBE_DEFER` and other negative error codes from `of_irq_get()`.
--

commit 6845fba6088aa0e893f716aacd6cf99383012ca1
Author: Rosen Penev <rosenp@gmail.com>

dmaengine: fsldma: convert channel ioremap to devm_of_iomap

Replace of_iomap with devm_of_iomap for per-channel register
mappings. This eliminates the iounmap calls in both the probe
error path and fsl_dma_chan_remove, and simplifies the error
handling by returning directly on failure.

> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index ee6e595c2972c..0d73ce3dbfe6a 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c

[ ... ]

> @@ -1192,17 +1189,12 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
>  		 chan->irq ? chan->irq : fdev->irq);
>  
>  	return 0;

[Severity: High]
Is there a failure to propagate -EPROBE_DEFER and other negative error codes
from of_irq_get() here?

The commit 'dmaengine: fsldma: replace irq_of_parse_and_map with of_irq_get'
switched to of_irq_get() specifically to handle negative error codes such as
-EPROBE_DEFER.

However, the error handling logic in fsldma_request_irqs() maps all values <=
0 to -ENODEV:

drivers/dma/fsldma.c:fsldma_request_irqs() {
	...
		if (chan->irq <= 0) {
			chan_err(chan, "interrupts property missing in device tree\n");
			return -ENODEV;
		}
	...
}

This forces negative error codes like -EPROBE_DEFER to become -ENODEV,
defeating the purpose of the migration by permanently aborting the probe
instead of deferring it.

> -
> -out_iounmap_regs:
> -	iounmap(chan->regs);
> -	return err;
>  }
>  
>  static void fsl_dma_chan_remove(struct fsldma_chan *chan)
>  {
>  	tasklet_kill(&chan->tasklet);
>  	list_del(&chan->common.device_node);
> -	iounmap(chan->regs);

[Severity: High]
Are we leaking the IRQ mapping when removing the channel?

In an earlier patch in the series ('dmaengine: fsldma: convert to
platform_get_irq_optional()'), the call to irq_dispose_mapping(chan->irq) was
removed from fsl_dma_chan_remove().

However, chan->irq is acquired using of_irq_get() (or previously
irq_of_parse_and_map()), which internally calls irq_create_of_mapping() and
allocates a mapping in the IRQ domain.

This mapping must be explicitly disposed of. Because the cleanup call was
removed and never re-introduced, the IRQ mapping is permanently leaked
whenever a DMA channel is removed or the driver unbinds.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605220134.43295-1-rosenp@gmail.com?part=7