Re: [PATCH 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Error check for platform_get_irq() is always false due to u32 type mismatch.
- [High] Resource leak due to missing device-managed variant for wake IRQ setup.
--

--- Patch [3]: [PATCH 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC ---
commit c2bd64766eedbf6c5de5bc325d96283f217c6464
Author: Zi-Yu Chen <zychennvt@gmail.com>

arm64: dts: nuvoton: Add WDT node for MA35D1 SoC

Add Watchdog Timer (WDT) device node to ma35d1.dtsi.

> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> index 7228ad4735b5c..14fd17cfdc5ae 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> @@ -82,6 +82,13 @@ soc {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		wdt1: watchdog@40440000 {
> +			compatible = "nuvoton,ma35d1-wdt";

[Severity: High]
Does adding this device node trigger a probe regression if platform_get_irq()
returns a negative error code like -EPROBE_DEFER?

Looking at ma35d1_wdt_probe() in drivers/watchdog/ma35d1_wdt.c:

	ma35d1_wdt->irq = platform_get_irq(pdev, 0);
	if (ma35d1_wdt->irq < 0)
		return dev_err_probe(dev, ma35d1_wdt->irq,
				     "failed to get irq\n");

If ma35d1_wdt->irq is a u32, the negative error code is implicitly cast to a
large positive number, making the check evaluate to false.

Will this cause probe errors to be ignored and devm_request_irq() to be
called with an invalid IRQ number, resulting in -EINVAL and breaking the probe
deferral mechanism?

[Severity: High]
Could this also lead to a resource leak when setting the wake IRQ?

Looking further in ma35d1_wdt_probe() in drivers/watchdog/ma35d1_wdt.c:

		ret = dev_pm_set_wake_irq(dev, ma35d1_wdt->irq);
		if (ret)
			return ret;

Since dev_pm_set_wake_irq() is used instead of the device-managed variant
devm_pm_set_wake_irq(), and the driver relies on devm_ interfaces without a
.remove callback, will the wake IRQ remain attached to the device structure if
the driver is unbound or a subsequent probe step fails?

Can this leave a dangling wake IRQ and potentially cause a use-after-free
when the device is destroyed?

> +			reg = <0x0 0x40440000 0x0 0x100>;
> +			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&clk WDT1_GATE>;
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723060755.1596858-1-zychennvt@gmail.com?part=3