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

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

Pre-existing issues:
- [High] Missing cleanup of `dev_pm_set_wake_irq()` leads to a memory leak and causes subsequent probes to fail permanently with `-EEXIST`.
--

--- Patch [2]: [PATCH v2 2/2] watchdog: stm32_iwdg: Propagate errors from optional IRQ lookup ---
commit 2e08fbcd4cd54dae1e6ee4882052b35d6df14b51
Author: bui duc phuc <[email protected]>

watchdog: stm32_iwdg: Propagate errors from optional IRQ lookup

This commit updates the IRQ initialization in the stm32_iwdg watchdog
driver to properly propagate errors from platform_get_irq_optional(). It
ensures that errors such as -EPROBE_DEFER or -EINVAL are passed back to
the caller, rather than continuing the probe without an IRQ. The -ENXIO
return value is still treated as a missing optional IRQ and handled
gracefully.

Link v1: https://lore.kernel.org/all/[email protected]/

> diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
> index b356a272ff9a0..a8d2db2d3cf8b 100644
> --- a/drivers/watchdog/stm32_iwdg.c
> +++ b/drivers/watchdog/stm32_iwdg.c
> @@ -287,8 +287,11 @@ static int stm32_iwdg_irq_init(struct platform_device *pdev,
>  		return 0;
>  
>  	irq = platform_get_irq_optional(pdev, 0);
> -	if (irq <= 0)
> +	if (irq < 0) {
> +		if (irq != -ENXIO)
> +			return irq;
>  		return 0;
> +	}
>  
>  	if (of_property_read_bool(np, "wakeup-source")) {
>  		ret = devm_device_init_wakeup(dev);

[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?

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