[PATCH v2 1/2] watchdog: orion_wdt: Propagate errors from optional IRQ lookup

[PATCH v2 1/2] watchdog: orion_wdt: Propagate errors from optional IRQ lookup

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no IRQ is available, while other errors should be propagated.

Propagate errors such as -EPROBE_DEFER and -EINVAL instead of continuing
probe without the IRQ.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Link v1:
https://lore.kernel.org/all/20260806062812.26523-1-phucduc.bui@gmail.com/
Changes in v2:
 - Update the commit message and error handling.
 - Propagate all errors from platform_get_irq_optional() except -ENXIO,
   instead of only handling -EPROBE_DEFER.

 drivers/watchdog/orion_wdt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 0e145f762f6f..f79a14c4e222 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -606,6 +606,8 @@ static int orion_wdt_probe(struct platform_device *pdev)
 
 	/* Request the IRQ only after the watchdog is disabled */
 	irq = platform_get_irq_optional(pdev, 0);
+	if (irq < 0 && irq != -ENXIO)
+		return irq;
 	if (irq > 0) {
 		/*
 		 * Not all supported platforms specify an interrupt for the
-- 
2.43.0

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

[phucduc.bui]

From: bui duc phuc <phucduc.bui@gmail.com>

platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no IRQ is available, while other errors should be propagated.

Propagate errors such as -EPROBE_DEFER and -EINVAL instead of continuing
probe without the IRQ.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---

Link v1:
https://lore.kernel.org/all/20260806062812.26523-2-phucduc.bui@gmail.com/
Changes in v2:
 - Update the commit message and error handling.
 - Propagate all errors from platform_get_irq_optional() except -ENXIO,
   instead of only handling -EPROBE_DEFER.

 drivers/watchdog/stm32_iwdg.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index b356a272ff9a..a8d2db2d3cf8 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);
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Returning directly on `platform_get_irq_optional` error bypasses clock cleanup, resulting in a resource leak.
--

--- Patch [1]: [PATCH v2 1/2] watchdog: orion_wdt: Propagate errors from optional IRQ lookup ---
commit 2b23b971e11df73076724d1b0329016fb3313456
Author: bui duc phuc <phucduc.bui@gmail.com>

watchdog: orion_wdt: Propagate errors from optional IRQ lookup

This commit updates the optional IRQ handling in the probe function. Instead
of continuing without an IRQ on all errors, it propagates errors other than
-ENXIO (such as -EPROBE_DEFER or -EINVAL) returned by
platform_get_irq_optional().

Link: https://lore.kernel.org/all/20260806062812.26523-1-phucduc.bui@gmail.com/

> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
> --- a/drivers/watchdog/orion_wdt.c
> +++ b/drivers/watchdog/orion_wdt.c
> @@ -606,6 +606,8 @@ static int orion_wdt_probe(struct platform_device *pdev)
>  
>  	/* Request the IRQ only after the watchdog is disabled */
>  	irq = platform_get_irq_optional(pdev, 0);
> +	if (irq < 0 && irq != -ENXIO)
> +		return irq;

[Severity: High]
Does this early return bypass the clock cleanup? 

Earlier in orion_wdt_probe(), the hardware clock is initialized and enabled by
dev->data->clock_init(pdev, dev). The other error paths in this function jump
to the disable_clk label to clean it up.

If we return directly here when an error like -EPROBE_DEFER occurs, it appears
we might leak the hardware clock reference and its enablement state because we
bypass clk_disable_unprepare() and clk_put() in the disable_clk error path. 
This could lead to repeated resource leaks if probe deferral happens multiple 
times.

Should this use goto disable_clk instead of returning directly?

>  	if (irq > 0) {
>  		/*
>  		 * Not all supported platforms specify an interrupt for the

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807080447.35479-1-phucduc.bui@gmail.com?part=1

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

[sashiko-bot]

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 <phucduc.bui@gmail.com>

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/20260806062812.26523-2-phucduc.bui@gmail.com/

> 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/20260807080447.35479-1-phucduc.bui@gmail.com?part=2

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

[Bui Duc Phuc]

> [Severity: High]
> Does this early return bypass the clock cleanup?
>
> Earlier in orion_wdt_probe(), the hardware clock is initialized and enabled by
> dev->data->clock_init(pdev, dev). The other error paths in this function jump
> to the disable_clk label to clean it up.
>
> If we return directly here when an error like -EPROBE_DEFER occurs, it appears
> we might leak the hardware clock reference and its enablement state because we
> bypass clk_disable_unprepare() and clk_put() in the disable_clk error path.
> This could lead to repeated resource leaks if probe deferral happens multiple
> times.
>
> Should this use goto disable_clk instead of returning directly?
>

I agree that this makes sense. I'll make the change and send v3.

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

[Bui Duc Phuc]

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

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

[Guenter Roeck]

On Fri, Aug 07, 2026 at 03:04:47PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
> 
> platform_get_irq_optional() returns a positive IRQ number on success or
> a negative error code on failure. For an optional IRQ, -ENXIO indicates
> that no IRQ is available, while other errors should be propagated.
> 
> Propagate errors such as -EPROBE_DEFER and -EINVAL instead of continuing
> probe without the IRQ.
> 
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>

Applie.

Thanks,
Guenter