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

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 s=
etup.
--

--- Patch [3]: [PATCH 3/3] arm64: dts: nuvoton: Add WDT node for MA35D1 SoC=
 ---
commit c2bd64766eedbf6c5de5bc325d96283f217c6464
Author: Zi-Yu Chen <[email protected]>

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/dt=
s/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 =3D <2>;
>  		ranges;
> =20
> +		wdt1: watchdog@40440000 {
> +			compatible =3D "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 =3D 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 pr=
obe
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 =3D 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 =3D <0x0 0x40440000 0x0 0x100>;
> +			interrupts =3D <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks =3D <&clk WDT1_GATE>;
> +		};

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260723060755.1596=
[email protected]?part=3D3