[PATCH] soc: fsl: dpio: Release the I/O object on IRQ registration failure

IRQ registration happens after dpaa2_io_create(), but its failure path
only releases the IRQ resources and the MC portal. The I/O object stays
allocated and published in the service list and per-CPU lookup table,
while devres unmaps its portal registers after probe fails.

Call dpaa2_io_down() on IRQ registration failure to remove the object
from those lookup structures and free it. Reorder the error labels so
that a failed dpaa2_io_create() still skips this cleanup.

This issue was identified during our ongoing static-analysis research
while reviewing kernel code.

Fixes: fe8fe7723a3a ("soc: fsl: dpio: register dpio irq handlers after dpio create")
Assisted-by: LLM
Co-developed-by: Ijae Kim <redacted>
Signed-off-by: Ijae Kim <redacted>
Signed-off-by: Myeonghun Pak <redacted>
---
 drivers/soc/fsl/dpio/dpio-driver.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c

@@ -244,9 +244,10 @@
 
 	return 0;
 
+err_register_dpio_irq:
+	dpaa2_io_down(priv->io);
 err_dpaa2_io_create:
 	unregister_dpio_irq_handlers(dpio_dev);
-err_register_dpio_irq:
 	fsl_mc_free_irqs(dpio_dev);
 err_allocate_irqs:
 	dpio_disable(dpio_dev->mc_io, 0, dpio_dev->mc_handle);

-- 
2.47.1

On Thu, Sep 17, 2026 at 04:01:38PM -0400, Myeonghun Pak wrote:

Agreed, if register_dpio_irq_handlers() fails then the dpaa2_io_down()
should be called.

But if dpaa2_io_create() fails should we still call
unregister_dpio_irq_handlers() considering that the probe path didn't
even reach register_dpio_irq_handlers()?

Please also fix that in a v2.

Thanks,
Ioana