Linux Watchdog driver development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2 1/2] watchdog: orion_wdt: Propagate errors from optional IRQ lookup
Date: Fri, 07 Aug 2026 08:11:08 +0000	[thread overview]
Message-ID: <20260807081108.B61881F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807080447.35479-1-phucduc.bui@gmail.com>

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

  parent reply	other threads:[~2026-08-07  8:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07  8:04 [PATCH v2 1/2] watchdog: orion_wdt: Propagate errors from optional IRQ lookup phucduc.bui
2026-08-07  8:04 ` [PATCH v2 2/2] watchdog: stm32_iwdg: " phucduc.bui
2026-08-07  8:17   ` sashiko-bot
2026-08-08  9:24     ` Bui Duc Phuc
2026-08-09 15:07   ` Guenter Roeck
2026-08-07  8:11 ` sashiko-bot [this message]
2026-08-08  9:18   ` [PATCH v2 1/2] watchdog: orion_wdt: " Bui Duc Phuc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260807081108.B61881F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=phucduc.bui@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox