On Thu, Sep 17, 2026 at 04:01:38PM -0400, Myeonghun Pak wrote:
> 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 <[email protected]>
> Signed-off-by: Ijae Kim <[email protected]>
> Signed-off-by: Myeonghun Pak <[email protected]>
> ---
> 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);
Agreed, if register_dpio_irq_handlers() fails then the dpaa2_io_down()
should be called.
> err_dpaa2_io_create:
> unregister_dpio_irq_handlers(dpio_dev);
> -err_register_dpio_irq:
> fsl_mc_free_irqs(dpio_dev);
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
