Re: [PATCH v2 2/2] watchdog: stm32_iwdg: Propagate errors from optional IRQ lookup

>
> [Severity: High]
> This is a pre-existing issue, but since we are adjusting the error handling
> around IRQs here, is there a missing cleanup path for the wake IRQ?
>
> A bit further down in stm32_iwdg_irq_init(), the code calls the unmanaged
> dev_pm_set_wake_irq(dev, irq) function:
>
>         if (of_property_read_bool(np, "wakeup-source")) {
>                 ...
>                 ret = dev_pm_set_wake_irq(dev, irq);
>                 if (ret)
>                         return ret;
>         }
>
>         ret = devm_request_irq(dev, irq, stm32_iwdg_isr, ...);
>
> If devm_request_irq() fails immediately after, or if a subsequent setup step
> like stm32_iwdg_start() fails in stm32_iwdg_probe(), the wake IRQ remains
> attached because dev_pm_set_wake_irq() does not automatically clean up on
> failure or device unbind.
>
> Could this cause the memory for the wake IRQ to leak and leave a dangling
> pointer in dev->power.wakeirq? If a probe deferral or unbind occurs,
> would the next probe attempt fail permanently with -EEXIST when
> dev_pm_set_wake_irq() encounters the dangling pointer? Would using
> devm_pm_set_wake_irq() here instead ensure proper lifecycle management?
>

This could be the case. However, I don't have the hardware available to
test and verify this issue.
Since this is a pre-existing issue and is outside the scope of this patch,
I would prefer to address it separately if it is confirmed.