[PATCH 0/7] Add reset support to MT6589 wdt and remove fallback compatibles

[PATCH 0/7] Add reset support to MT6589 wdt and remove fallback compatibles

[Akari Tsuyukusa]

This series adds TOPRGU reset controller support to the MT6589 watchdog
and removes the use of "mediatek,mt6589-wdt" as the fallback compatible
from many other MediaTek SoCs.

Many SoCs have been using "mediatek,mt6589-wdt" as the fallback.
However, they are not compatible with the MT6589's reset register.

To add reset support to MT6589 wdt and resolve this problem safely,
the series proceeds step by step:

 1. Add explicit driver entries for the affected SoCs,
    so they can be matched directly.
 2. Extend the dt-binding to accept the SoC-specific compatibles while
    still allowing the old fallback form.
 3. Drop the mt6589 fallback from all in-tree DTS.
 4. Remove the fallback from the dt-binding.
 5. Add the MT6589 reset dt-binding header.
 6. Assign reset data exclusively to the mt6589-wdt entry.
 7. Add #reset-cells to the MT6589 to enable TOPRGU reset controller.


Akari Tsuyukusa (7):
  watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589
    fallback
  dt-bindings: watchdog: mediatek,mtk-wdt: add compatibles for all SoCs
  arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog
  dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items
  dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller
  watchdog: mtk_wdt: add reset controller support for MT6589
  arm: dts: mediatek: mt6589: add reset support for wdt

 .../bindings/watchdog/mediatek,mtk-wdt.yaml   | 26 ++++++++-----------
 arch/arm/boot/dts/mediatek/mt2701.dtsi        |  3 +--
 arch/arm/boot/dts/mediatek/mt6572.dtsi        |  2 +-
 arch/arm/boot/dts/mediatek/mt6582.dtsi        |  2 +-
 arch/arm/boot/dts/mediatek/mt6589.dtsi        |  1 +
 arch/arm/boot/dts/mediatek/mt7623.dtsi        |  3 +--
 arch/arm/boot/dts/mediatek/mt7629.dtsi        |  3 +--
 arch/arm64/boot/dts/mediatek/mt6797.dtsi      |  2 +-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi      |  3 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi      |  3 +--
 arch/arm64/boot/dts/mediatek/mt8365.dtsi      |  2 +-
 arch/arm64/boot/dts/mediatek/mt8516.dtsi      |  3 +--
 drivers/watchdog/mtk_wdt.c                    | 18 ++++++++++++-
 include/dt-bindings/reset/mt6589-resets.h     | 25 ++++++++++++++++++
 14 files changed, 64 insertions(+), 32 deletions(-)
 create mode 100644 include/dt-bindings/reset/mt6589-resets.h

-- 
2.54.0

[PATCH 1/7] watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589 fallback

[Akari Tsuyukusa]

Several SoCs currently rely on matching "mediatek,mt6589-wdt" via the
fallback compatible. Add dedicated of_device_id entries for each of
them so that the driver can match directly on the SoC-specific string.

This is a prerequisite for DTS to safely drop the fallback string.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 drivers/watchdog/mtk_wdt.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 91d110646e16..345d2e89f414 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -492,17 +492,28 @@ static int mtk_wdt_resume(struct device *dev)
 }
 
 static const struct of_device_id mtk_wdt_dt_ids[] = {
+	{ .compatible = "mediatek,mt2701-wdt" },
 	{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },
+	{ .compatible = "mediatek,mt6572-wdt" },
+	{ .compatible = "mediatek,mt6582-wdt" },
 	{ .compatible = "mediatek,mt6589-wdt" },
 	{ .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data },
 	{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
+	{ .compatible = "mediatek,mt6797-wdt" },
+	{ .compatible = "mediatek,mt7622-wdt" },
+	{ .compatible = "mediatek,mt7623-wdt" },
+	{ .compatible = "mediatek,mt7629-wdt" },
 	{ .compatible = "mediatek,mt7986-wdt", .data = &mt7986_data },
 	{ .compatible = "mediatek,mt7988-wdt", .data = &mt7988_data },
+	{ .compatible = "mediatek,mt8173-wdt" },
 	{ .compatible = "mediatek,mt8183-wdt", .data = &mt8183_data },
 	{ .compatible = "mediatek,mt8186-wdt", .data = &mt8186_data },
 	{ .compatible = "mediatek,mt8188-wdt", .data = &mt8188_data },
+	{ .compatible = "mediatek,mt8189-wdt" },
 	{ .compatible = "mediatek,mt8192-wdt", .data = &mt8192_data },
 	{ .compatible = "mediatek,mt8195-wdt", .data = &mt8195_data },
+	{ .compatible = "mediatek,mt8365-wdt" },
+	{ .compatible = "mediatek,mt8516-wdt" },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, mtk_wdt_dt_ids);
-- 
2.54.0

Re: [PATCH 1/7] watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589 fallback

[sashiko-bot]

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

Pre-existing issues:
- [High] Watchdog is registered to userspace before its state is fully initialized from the device tree.
- [High] Watchdog hardware is not stopped during system suspend if it was running before boot but not opened by userspace.
--

--- Patch [1]: [PATCH 1/7] watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589 fallback ---
commit d59566877973f13ae59e846770f459a7512fd9eb
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

watchdog: mtk_wdt: add explicit compatibles for SoCs using mt6589 fallback

This patch adds dedicated of_device_id entries for several SoCs that
currently rely on the "mediatek,mt6589-wdt" fallback compatible. This
allows the driver to match directly on the SoC-specific string, which is
a prerequisite for removing the fallback string from DTS files.

> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 91d110646e16f..345d2e89f414e 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -492,17 +492,28 @@ static int mtk_wdt_resume(struct device *dev)
>  }

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential
problem with how the watchdog is handled during system suspend and resume.

In mtk_wdt_suspend() and mtk_wdt_resume(), the driver only checks
watchdog_active(), which is true if userspace has opened the device:

drivers/watchdog/mtk_wdt.c:mtk_wdt_suspend() {
    ...
	if (watchdog_active(&mtk_wdt->wdt_dev))
		mtk_wdt_stop(&mtk_wdt->wdt_dev);
    ...
}

Will this cause the system to reboot unexpectedly during suspend if the
hardware watchdog was already running before boot (WDOG_HW_RUNNING) but
hasn't been opened by userspace?

Should these functions also ensure the hardware is properly stopped even
when the device hasn't been opened?

[Severity: High]
This is also a pre-existing issue, but does mtk_wdt_probe() expose the
device to userspace too early?

drivers/watchdog/mtk_wdt.c:mtk_wdt_probe() {
    ...
	err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
	if (unlikely(err))
		return err;

	// ... [code omitted] ...

	mtk_wdt->disable_wdt_extrst =
		of_property_read_bool(dev->of_node, "mediatek,disable-extrst");

	mtk_wdt->reset_by_toprgu =
		of_property_read_bool(dev->of_node, "mediatek,reset-by-toprgu");
    ...
}

If userspace opens and starts the watchdog immediately after
devm_watchdog_register_device() completes, could it be started with
incorrect configurations before the device tree properties are parsed?

Additionally, if toprgu_register_reset_controller() fails after the watchdog
is registered, the probe will fail. Could this cause the watchdog to be
deregistered while it is actively in use by userspace?

>  
>  static const struct of_device_id mtk_wdt_dt_ids[] = {
> +	{ .compatible = "mediatek,mt2701-wdt" },
>  	{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716161923.266315-1-akkun11.open@gmail.com?part=1

[PATCH 2/7] dt-bindings: watchdog: mediatek,mtk-wdt: add compatibles for all SoCs

[Akari Tsuyukusa]

The driver recognizes each SoC-specific compatible, update the binding
to list them in the top-level enum alongside the existing ones. Keep
the fallback items definition so that old DTS continue to validate.

Affected SoCs: mt2701, mt6572, mt6582, mt6797, mt7622, mt7623,
mt7629, mt8173, mt8189, mt8365, mt8516.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 .../bindings/watchdog/mediatek,mtk-wdt.yaml           | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..f4eaa5f7c5bc 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -20,17 +20,28 @@ properties:
   compatible:
     oneOf:
       - enum:
+          - mediatek,mt2701-wdt
           - mediatek,mt2712-wdt
+          - mediatek,mt6572-wdt
+          - mediatek,mt6582-wdt
           - mediatek,mt6589-wdt
           - mediatek,mt6735-wdt
           - mediatek,mt6795-wdt
+          - mediatek,mt6797-wdt
+          - mediatek,mt7622-wdt
+          - mediatek,mt7623-wdt
+          - mediatek,mt7629-wdt
           - mediatek,mt7986-wdt
           - mediatek,mt7988-wdt
+          - mediatek,mt8173-wdt
           - mediatek,mt8183-wdt
           - mediatek,mt8186-wdt
           - mediatek,mt8188-wdt
+          - mediatek,mt8189-wdt
           - mediatek,mt8192-wdt
           - mediatek,mt8195-wdt
+          - mediatek,mt8365-wdt
+          - mediatek,mt8516-wdt
       - items:
           - enum:
               - mediatek,mt2701-wdt
-- 
2.54.0

[PATCH 3/7] arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog

[Akari Tsuyukusa]

Remove the "mediatek,mt6589-wdt" fallback string from all in-tree
device trees. Use only the SoC-specific compatible.

No functional change.
Affected SoCs: mt2701, mt6572, mt6582, mt6797, mt7622, mt7623,
mt7629, mt8173, mt8365, mt8516.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 arch/arm/boot/dts/mediatek/mt2701.dtsi   | 3 +--
 arch/arm/boot/dts/mediatek/mt6572.dtsi   | 2 +-
 arch/arm/boot/dts/mediatek/mt6582.dtsi   | 2 +-
 arch/arm/boot/dts/mediatek/mt7623.dtsi   | 3 +--
 arch/arm/boot/dts/mediatek/mt7629.dtsi   | 3 +--
 arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 3 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 3 +--
 arch/arm64/boot/dts/mediatek/mt8365.dtsi | 2 +-
 arch/arm64/boot/dts/mediatek/mt8516.dtsi | 3 +--
 10 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/mediatek/mt2701.dtsi b/arch/arm/boot/dts/mediatek/mt2701.dtsi
index 128b87229f3d..f23a6d860a53 100644
--- a/arch/arm/boot/dts/mediatek/mt2701.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt2701.dtsi
@@ -160,8 +160,7 @@ scpsys: power-controller@10006000 {
 	};
 
 	watchdog: watchdog@10007000 {
-		compatible = "mediatek,mt2701-wdt",
-			     "mediatek,mt6589-wdt";
+		compatible = "mediatek,mt2701-wdt";
 		reg = <0 0x10007000 0 0x100>;
 	};
 
diff --git a/arch/arm/boot/dts/mediatek/mt6572.dtsi b/arch/arm/boot/dts/mediatek/mt6572.dtsi
index ac70f266d698..5a6c9763bd6c 100644
--- a/arch/arm/boot/dts/mediatek/mt6572.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6572.dtsi
@@ -53,7 +53,7 @@ soc {
 		ranges;
 
 		watchdog: watchdog@10007000 {
-			compatible = "mediatek,mt6572-wdt", "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt6572-wdt";
 			reg = <0x10007000 0x100>;
 			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
 			timeout-sec = <15>;
diff --git a/arch/arm/boot/dts/mediatek/mt6582.dtsi b/arch/arm/boot/dts/mediatek/mt6582.dtsi
index f941ea44898a..501aeb3a2848 100644
--- a/arch/arm/boot/dts/mediatek/mt6582.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6582.dtsi
@@ -63,7 +63,7 @@ soc {
 		ranges;
 
 		watchdog: watchdog@10007000 {
-			compatible = "mediatek,mt6582-wdt", "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt6582-wdt";
 			reg = <0x10007000 0x100>;
 		};
 
diff --git a/arch/arm/boot/dts/mediatek/mt7623.dtsi b/arch/arm/boot/dts/mediatek/mt7623.dtsi
index aa42377b47da..48d6c348f667 100644
--- a/arch/arm/boot/dts/mediatek/mt7623.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt7623.dtsi
@@ -281,8 +281,7 @@ scpsys: power-controller@10006000 {
 	};
 
 	watchdog: watchdog@10007000 {
-		compatible = "mediatek,mt7623-wdt",
-			     "mediatek,mt6589-wdt";
+		compatible = "mediatek,mt7623-wdt";
 		reg = <0 0x10007000 0 0x100>;
 	};
 
diff --git a/arch/arm/boot/dts/mediatek/mt7629.dtsi b/arch/arm/boot/dts/mediatek/mt7629.dtsi
index acab0883a3bb..b034e9ab5af1 100644
--- a/arch/arm/boot/dts/mediatek/mt7629.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt7629.dtsi
@@ -141,8 +141,7 @@ topckgen: syscon@10210000 {
 		};
 
 		watchdog: watchdog@10212000 {
-			compatible = "mediatek,mt7629-wdt",
-				     "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt7629-wdt";
 			reg = <0x10212000 0x100>;
 		};
 
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index 8ac98a378fd6..fe81faee0b0c 100644
--- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
@@ -218,7 +218,7 @@ scpsys: power-controller@10006000 {
 	};
 
 	watchdog: watchdog@10007000 {
-		compatible = "mediatek,mt6797-wdt", "mediatek,mt6589-wdt";
+		compatible = "mediatek,mt6797-wdt";
 		reg = <0 0x10007000 0 0x100>;
 	};
 
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 158bd9a305d7..0b5ffe9fa806 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -322,8 +322,7 @@ pio: pinctrl@10211000 {
 	};
 
 	watchdog: watchdog@10212000 {
-		compatible = "mediatek,mt7622-wdt",
-			     "mediatek,mt6589-wdt";
+		compatible = "mediatek,mt7622-wdt";
 		reg = <0 0x10212000 0 0x800>;
 	};
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 78c2ccd5be13..04b91b751853 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -528,8 +528,7 @@ power-domain@MT8173_POWER_DOMAIN_MFG {
 		};
 
 		watchdog: watchdog@10007000 {
-			compatible = "mediatek,mt8173-wdt",
-				     "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt8173-wdt";
 			reg = <0 0x10007000 0 0x100>;
 		};
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
index 2e782558fb77..2b5b761b92c8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -469,7 +469,7 @@ power-domain@MT8365_POWER_DOMAIN_DSP {
 		};
 
 		watchdog: watchdog@10007000 {
-			compatible = "mediatek,mt8365-wdt", "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt8365-wdt";
 			reg = <0 0x10007000 0 0x100>;
 			#reset-cells = <1>;
 		};
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index b5e753759465..515eed0bee21 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -203,8 +203,7 @@ apmixedsys: apmixedsys@10018000 {
 		};
 
 		watchdog@10007000 {
-			compatible = "mediatek,mt8516-wdt",
-				     "mediatek,mt6589-wdt";
+			compatible = "mediatek,mt8516-wdt";
 			reg = <0 0x10007000 0 0x1000>;
 			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
 			#reset-cells = <1>;
-- 
2.54.0

Re: [PATCH 3/7] arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Removing the fallback compatible string 'mediatek,mt6589-wdt' from device trees breaks forward compatibility (ABI breakage) with older kernels.

Device trees are treated as a stable ABI in Linux, meaning a newly compiled Device Tree Blob (DTB) must be able to boot successfully on older kernels. Older LTS/stable kernels rely entirely on the generic 'mediatek,mt6589-wdt' fallback string to probe the watchdog driver for these Mediatek SoCs (e.g., mt2701, mt6572, mt8173), because older driver versions do not include the SoC-specific strings in their `of_match_table`.

By removing the fallback string from the `.dtsi` files, a new DTB will fail to bind the watchdog driver on any older kernel. Because this watchdog driver also registers the system's reset controller (`toprgu_register_reset_controller()`), its failure to probe will cascade, breaking other devices that depend on those resets.

Although the previous patch in this series added the specific compatibles to the new kernel's driver, standard Device Tree practice dictates that valid fallback strings must not be removed once they have been established, precisely to preserve compatibility with older kernels.
--

--- Patch [3]: [PATCH 3/7] arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog ---
commit 32f0d12ddf1053eabd5133b535f4e55a874b71e9
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog

This commit removes the "mediatek,mt6589-wdt" fallback string from several
Mediatek device trees, leaving only the SoC-specific compatibles.

> diff --git a/arch/arm/boot/dts/mediatek/mt2701.dtsi b/arch/arm/boot/dts/mediatek/mt2701.dtsi
> index 128b87229f3d5..f23a6d860a53b 100644
> --- a/arch/arm/boot/dts/mediatek/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt2701.dtsi
> @@ -160,8 +160,7 @@ scpsys: power-controller@10006000 {
>  	};
>  
>  	watchdog: watchdog@10007000 {
> -		compatible = "mediatek,mt2701-wdt",
> -			     "mediatek,mt6589-wdt";
> +		compatible = "mediatek,mt2701-wdt";

[Severity: Critical]
Does removing the fallback string break ABI forward compatibility with older
kernels?

Device trees are typically treated as a stable ABI, meaning a newly compiled
DTB needs to boot successfully on older kernels. Older LTS or stable kernels
might rely entirely on the generic "mediatek,mt6589-wdt" fallback string to
probe the watchdog driver for these Mediatek SoCs, because older driver
versions do not include the SoC-specific strings in their of_match_table.

By removing the fallback string here and in the other included dtsi files,
will a new DTB fail to bind the watchdog driver on an older kernel? Because
this watchdog driver also registers the system's reset controller, this
failure could cascade and break other devices that depend on those resets.

>  		reg = <0 0x10007000 0 0x100>;
>  	};
>  

[ ... ]

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

Re: [PATCH 3/7] arm/arm64: dts: mediatek: drop mt6589 fallback from watchdog

[Roman Vivchar]

Hi,

On Thursday, July 16th, 2026 at 7:19 PM, Akari Tsuyukusa <akkun11.open@gmail.com> wrote:

> Remove the "mediatek,mt6589-wdt" fallback string from all in-tree
> device trees. Use only the SoC-specific compatible.
>
> No functional change.
> Affected SoCs: mt2701, mt6572, mt6582, mt6797, mt7622, mt7623,
> mt7629, mt8173, mt8365, mt8516.
> 
> Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>

...

> diff --git a/arch/arm/boot/dts/mediatek/mt6572.dtsi b/arch/arm/boot/dts/mediatek/mt6572.dtsi
> index ac70f266d698..5a6c9763bd6c 100644
> --- a/arch/arm/boot/dts/mediatek/mt6572.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt6572.dtsi
> @@ -53,7 +53,7 @@ soc {
>  		ranges;
> 
>  		watchdog: watchdog@10007000 {
> -			compatible = "mediatek,mt6572-wdt", "mediatek,mt6589-wdt";
> +			compatible = "mediatek,mt6572-wdt";
>  			reg = <0x10007000 0x100>;
>  			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
>  			timeout-sec = <15>;

mt6572 downstream kernel shows the same layout as 6589, but only
pwrap, md lite and md are explicitly referenced and used.

I tried poking some unused bits like DDR PHY or INFRA AO, though
that appears to be no-op. Only MMSYS and APMIXED resets from
the 6589 worked for me so far.

=> mw.l 0x10007018 0x88000001 # infra
=> mw.l 0x10007018 0x88000002 # mm
* display died * 
=> mw.l 0x10007018 0x88000004 # mfg
=> mw.l 0x10007018 0x88000040 # ddrphy
=> mw.l 0x10007018 0x88000100 # infra_ao
=> mw.l 0x10007018 0x88000400 # apmixed
* hang *

I assume others are reserved on mt6572, so

Acked-by: Roman Vivchar <rva333@protonmail.com> # for mt6572

Best regards,
Roman

[PATCH 4/7] dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items

[Akari Tsuyukusa]

All DTS have been converted to standalone compatibles.
Remove the items block that allowed the "mediatek,mt6589-wdt" fallback,
keeping only the flat enum.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 .../bindings/watchdog/mediatek,mtk-wdt.yaml       | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index f4eaa5f7c5bc..2411c02f1cb0 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -42,21 +42,6 @@ properties:
           - mediatek,mt8195-wdt
           - mediatek,mt8365-wdt
           - mediatek,mt8516-wdt
-      - items:
-          - enum:
-              - mediatek,mt2701-wdt
-              - mediatek,mt6572-wdt
-              - mediatek,mt6582-wdt
-              - mediatek,mt6797-wdt
-              - mediatek,mt7622-wdt
-              - mediatek,mt7623-wdt
-              - mediatek,mt7629-wdt
-              - mediatek,mt8173-wdt
-              - mediatek,mt8188-wdt
-              - mediatek,mt8189-wdt
-              - mediatek,mt8365-wdt
-              - mediatek,mt8516-wdt
-          - const: mediatek,mt6589-wdt
 
   reg:
     maxItems: 1
-- 
2.54.0

Re: [PATCH 4/7] dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items

[sashiko-bot]

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

New issues:
- [Medium] Removing the fallback `items` block breaks schema validation for existing older Device Trees.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the schema fails to conditionally enforce `#reset-cells` as a required property for watchdog variants that act as reset providers.
--

--- Patch [4]: [PATCH 4/7] dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items ---
commit 51d21b22f4b3e7a458ffe7ba34258074ee5dc9ac
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

dt-bindings: watchdog: mediatek,mtk-wdt: remove mt6589 fallback items

This commit removes the fallback items block for the mediatek,mt6589-wdt
compatible string from the MediaTek watchdog binding. It retains only the
flat enum, under the premise that all DTS files have been converted to
standalone compatibles.

> diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> index f4eaa5f7c5bc3..2411c02f1cb0f 100644
> --- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
> @@ -42,21 +42,6 @@ properties:
>            - mediatek,mt8195-wdt
>            - mediatek,mt8365-wdt
>            - mediatek,mt8516-wdt
> -      - items:
> -          - enum:
> -              - mediatek,mt2701-wdt
> -              - mediatek,mt6572-wdt
> -              - mediatek,mt6582-wdt

[Severity: Medium]
Will removing this fallback block cause validation regressions for existing
older device trees?

If users run dtbs_check against older device trees containing compatible
arrays like "mediatek,mt8516-wdt", "mediatek,mt6589-wdt", they will now
fail validation.

[ ... ]

Looking at the required properties list further down in
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml:

>   '#reset-cells':
>     const: 1
> 
> required:
>   - compatible
>   - reg

[Severity: High]
This is a pre-existing issue, but does the schema fail to conditionally
enforce #reset-cells as a required property for watchdog variants that act
as reset providers?

If device trees omit this property for reset provider variants like
"mediatek,mt8188-wdt", they silently pass validation. Dependent subsystems
relying on the reset line will then fail at runtime when attempting to use
the undocumented functionality.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716161923.266315-1-akkun11.open@gmail.com?part=4

[PATCH 5/7] dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller

[Akari Tsuyukusa]

Add MT6589 reset controller bindings.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 include/dt-bindings/reset/mt6589-resets.h | 25 +++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 include/dt-bindings/reset/mt6589-resets.h

diff --git a/include/dt-bindings/reset/mt6589-resets.h b/include/dt-bindings/reset/mt6589-resets.h
new file mode 100644
index 000000000000..18ef729022a9
--- /dev/null
+++ b/include/dt-bindings/reset/mt6589-resets.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2026 Akari Tsuyukusa <akkun11.open@gmail.com>
+ */
+
+#ifndef _DT_BINDINGS_RESET_MT6589_RESETS_H
+#define _DT_BINDINGS_RESET_MT6589_RESETS_H
+
+/* TOPRGU */
+#define MT6589_TOPRGU_INFRA_RST		0
+#define MT6589_TOPRGU_DISP_RST		1
+#define MT6589_TOPRGU_MFG_RST		2
+#define MT6589_TOPRGU_VENC_RST		3
+#define MT6589_TOPRGU_VDEC_RST		4
+#define MT6589_TOPRGU_IMG_RST		5
+#define MT6589_TOPRGU_DDRPHY_RST	6
+#define MT6589_TOPRGU_MD_RST		7
+#define MT6589_TOPRGU_INFRA_AO_RST	8
+#define MT6589_TOPRGU_MD_LITE_RST	9
+#define MT6589_TOPRGU_APMIXED_RST	10
+#define MT6589_TOPRGU_PWRAP_SPICTL_RST	11
+
+#define MT6589_TOPRGU_RST_NUM		12
+
+#endif  /* _DT_BINDINGS_RESET_MT6589_RESETS_H */
-- 
2.54.0

Re: [PATCH 5/7] dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The mediatek,mtk-wdt.yaml binding schema was not updated to require #reset-cells for the MT6589 watchdog hardware variant.
--

--- Patch [5]: [PATCH 5/7] dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller ---
commit b3f415af68c03c846f8813bd551b69190964c62a
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

dt-bindings: reset: Add bindings for MediaTek MT6589 reset controller

This commit adds the reset controller index definitions for the MediaTek
MT6589 SoC. It defines 12 reset lines under the TOPRGU controller.

> diff --git a/include/dt-bindings/reset/mt6589-resets.h b/include/dt-bindings/reset/mt6589-resets.h
> new file mode 100644
> --- /dev/null
> +++ b/include/dt-bindings/reset/mt6589-resets.h
> @@ -0,0 +1,25 @@
[ ... ]
> +/* TOPRGU */
> +#define MT6589_TOPRGU_INFRA_RST		0
> +#define MT6589_TOPRGU_DISP_RST		1
[ ... ]
> +#define MT6589_TOPRGU_PWRAP_SPICTL_RST	11
> +
> +#define MT6589_TOPRGU_RST_NUM		12
> +
> +#endif  /* _DT_BINDINGS_RESET_MT6589_RESETS_H */

[Severity: Medium]
Should Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml also
be updated to require the #reset-cells property for the MT6589 variant?

Since this patch introduces the MT6589 hardware as a reset provider, device 
tree nodes lacking the #reset-cells property for mediatek,mt6589-wdt might
incorrectly pass schema validation. Would it make sense to add an if-then
block to the YAML schema in this series to enforce the #reset-cells
requirement?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716161923.266315-1-akkun11.open@gmail.com?part=5

[PATCH 6/7] watchdog: mtk_wdt: add reset controller support for MT6589

[Akari Tsuyukusa]

Now that no other SoC depends on the mt6589 fallback, it is safe to
assign reset data to the mt6589 entry.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 drivers/watchdog/mtk_wdt.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 345d2e89f414..c8ce45a59795 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -10,6 +10,7 @@
  */
 
 #include <dt-bindings/reset/mt2712-resets.h>
+#include <dt-bindings/reset/mt6589-resets.h>
 #include <dt-bindings/reset/mediatek,mt6735-wdt.h>
 #include <dt-bindings/reset/mediatek,mt6795-resets.h>
 #include <dt-bindings/reset/mt7986-resets.h>
@@ -88,6 +89,10 @@ static const struct mtk_wdt_data mt2712_data = {
 	.toprgu_sw_rst_num = MT2712_TOPRGU_SW_RST_NUM,
 };
 
+static const struct mtk_wdt_data mt6589_data = {
+	.toprgu_sw_rst_num = MT6589_TOPRGU_RST_NUM,
+};
+
 static const struct mtk_wdt_data mt6735_data = {
 	.toprgu_sw_rst_num = MT6735_TOPRGU_RST_NUM,
 };
@@ -496,7 +501,7 @@ static const struct of_device_id mtk_wdt_dt_ids[] = {
 	{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },
 	{ .compatible = "mediatek,mt6572-wdt" },
 	{ .compatible = "mediatek,mt6582-wdt" },
-	{ .compatible = "mediatek,mt6589-wdt" },
+	{ .compatible = "mediatek,mt6589-wdt", .data = &mt6589_data },
 	{ .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data },
 	{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
 	{ .compatible = "mediatek,mt6797-wdt" },
-- 
2.54.0

Re: [PATCH 6/7] watchdog: mtk_wdt: add reset controller support for MT6589

[sashiko-bot]

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

Pre-existing issues:
- [High] The watchdog device and reset controller are registered before the driver has finished reading its configuration from the device tree.
--

--- Patch [6]: [PATCH 6/7] watchdog: mtk_wdt: add reset controller support for MT6589 ---
commit f121306c9b4fd3b69e7cdcb03d9c4a147f872914
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

watchdog: mtk_wdt: add reset controller support for MT6589
    
This commit adds reset data for the MT6589 fallback, assigning the proper
reset controller information to the mt6589 entry in the device tree match
table.

> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 345d2e89f414e..c8ce45a597956 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c

[ ... ]

> @@ -496,7 +501,7 @@ static const struct of_device_id mtk_wdt_dt_ids[] = {
>  	{ .compatible = "mediatek,mt2712-wdt", .data = &mt2712_data },
>  	{ .compatible = "mediatek,mt6572-wdt" },
>  	{ .compatible = "mediatek,mt6582-wdt" },
> -	{ .compatible = "mediatek,mt6589-wdt" },
> +	{ .compatible = "mediatek,mt6589-wdt", .data = &mt6589_data },

[Severity: High]
This is a pre-existing issue, but while reviewing the watchdog data
initialization, I noticed a potential race condition during device probe.

Is it possible for the watchdog device or reset controller to be accessed 
before their configuration flags are fully initialized?

In drivers/watchdog/mtk_wdt.c:mtk_wdt_probe():

	err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
	if (unlikely(err))
		return err;

	dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)\n",
		 mtk_wdt->wdt_dev.timeout, nowayout);

	wdt_data = of_device_get_match_data(dev);
	if (wdt_data) {
		err = toprgu_register_reset_controller(pdev,
						       wdt_data->toprgu_sw_rst_num);
		if (err)
			return err;

		mtk_wdt->has_swsysrst_en = wdt_data->has_swsysrst_en;
	}

	mtk_wdt->disable_wdt_extrst =
		of_property_read_bool(dev->of_node, "mediatek,disable-extrst");

	mtk_wdt->reset_by_toprgu =
		of_property_read_bool(dev->of_node, "mediatek,reset-by-toprgu");

If a userspace process opens the watchdog character device immediately after 
devm_watchdog_register_device() completes, or a concurrently probing driver 
acquires the reset controller after toprgu_register_reset_controller() 
returns, could they operate with uninitialized state variables 
(disable_wdt_extrst, reset_by_toprgu, and has_swsysrst_en)?

This could potentially misconfigure the hardware, failing to disable external 
resets or missing software reset enables, which might cause system lockups or 
failed peripheral resets.

>  	{ .compatible = "mediatek,mt6735-wdt", .data = &mt6735_data },
>  	{ .compatible = "mediatek,mt6795-wdt", .data = &mt6795_data },
>  	{ .compatible = "mediatek,mt6797-wdt" },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716161923.266315-1-akkun11.open@gmail.com?part=6

[PATCH 7/7] arm: dts: mediatek: mt6589: add reset support for wdt

[Akari Tsuyukusa]

Now the MediaTek watchdog driver supports MT6589 TOPRGU resets.
Add #reset-cells = <1>; to enable it.

Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
 arch/arm/boot/dts/mediatek/mt6589.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/mediatek/mt6589.dtsi b/arch/arm/boot/dts/mediatek/mt6589.dtsi
index 46dea445742b..2645054a4a61 100644
--- a/arch/arm/boot/dts/mediatek/mt6589.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6589.dtsi
@@ -147,6 +147,7 @@ uart3: serial@11009000 {
 		wdt: watchdog@10000000 {
 			compatible = "mediatek,mt6589-wdt";
 			reg = <0x10000000 0x44>;
+			#reset-cells = <1>;
 		};
 	};
 };
-- 
2.54.0

Re: [PATCH 7/7] arm: dts: mediatek: mt6589: add reset support for wdt

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The dt-binding schema fails to enforce `#reset-cells` as a required property for watchdog variants that act as reset providers, such as `mediatek,mt6589-wdt`.
--

--- Patch [7]: [PATCH 7/7] arm: dts: mediatek: mt6589: add reset support for wdt ---
commit 3940ed1252e6cfe8fc145910821de71c2c72776d
Author: Akari Tsuyukusa <akkun11.open@gmail.com>

arm: dts: mediatek: mt6589: add reset support for wdt

This commit updates the MT6589 watchdog device tree node to support TOPRGU
resets by adding the #reset-cells property.

> diff --git a/arch/arm/boot/dts/mediatek/mt6589.dtsi b/arch/arm/boot/dts/mediatek/mt6589.dtsi
> index c6babc8ad2ba6..4d29ed495d31e 100644
> --- a/arch/arm/boot/dts/mediatek/mt6589.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt6589.dtsi
> @@ -136,6 +136,7 @@ uart3: serial@11009000 {
>  		wdt: watchdog@10000000 {
>  			compatible = "mediatek,mt6589-wdt";
>  			reg = <0x10000000 0x44>;
> +			#reset-cells = <1>;

[Severity: Medium]
Does the device tree binding schema for mediatek,mtk-wdt need an update
alongside this change?

Adding #reset-cells here indicates this watchdog variant now acts as a reset
provider. According to the dt-bindings subsystem guidelines, when hardware
gains new provider capabilities, the corresponding standard properties (like
#reset-cells) must be added to the required list in the schema with
appropriate constraints.

Without an allOf with if-then conditional block in
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml to enforce
#reset-cells as required for mediatek,mt6589-wdt, functionally incomplete
device tree nodes missing this property will silently pass dt_binding_check
validation.

>  		};
>  	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716161923.266315-1-akkun11.open@gmail.com?part=7