Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
which in turn falls back on mt6589-wdt, which does not support toprgu
resets yet. This series adds support for mt6589 toprgu resets with bit
definitions obtained from Android stock sources.

However, according to its data sheet, mt8167 has 14 sw resets instead of
12, and the reset bits are non-contiguous. This is currently unsupported
by the mtk-wtd driver, and it caused confusion between reset IDs and reset
bits in device tree includes.

Therefore in the first three patches we improve the description of the,
resets for mt6589 using the definitions obtained from Android sources.

Then we introduce a dedicated mediatek,mt8167-wdt compatible for the
watchdog driver that describes correctly this SoC's resets. Also while
we're touching the bindings reset includes, we add IDs for the MMSYS
resets.

In the 5th patch we add support for a watchdog reset table to accommodate
the distinction between device tree reset IDs and the actual bits in the
registers. Code is inspired by the reset table currently implemented in the
mmsys driver. There should be no effect on existing sequential wdt resets.

In the 6th patch, we define the mmsys reset table for the SoC. According
to the datasheet, there are 28 mmsys reset bits divided across two
adjacent registers.

In the last patch we actually enable the watchdog driver for mt8167 by
adding a node for the mt8167 watchdog referring to the new compatible in
the SoC dtsi.

The series has been tested on a Sony PlayStation Classic Mini and on a
Lenovo Smart Clock 2.

Changes in v4:
- Squashed the reset IDs includes together with the bindings change;
- Added support for a reset table to the mtk-wdt driver. This allows us
  to decouple reset IDs from device trees from reset bits and lets us
  describe correctly the non-contiguous reset bits of mt8167;
- Improved explanations in commit messages.

Changes in v3 [3]:
- Improved explanations in the commit messages;
- Added the #reset-cells property to mt6589 watchdog node;
- Included the mediatek,mt6589-resets.h file in mt6589.dtsi;
- Included the mediatek,mt8167-resets.h file in mt8167.dtsi;
- Moved the mmsys reset table from the mt8167-mmsys.h header file to
  the mmsys driver implementation.

Changes in v2 [2]:
- Sashiko pointed out correctly a missing entry in the mmsys reset table
  in the last patch.

Initial version: [1]

[1] https://lore.kernel.org/linux-mediatek/20260717151134.678839-1-l.scorcia@gmail.com/
[2] https://lore.kernel.org/linux-mediatek/20260717163959.714561-1-l.scorcia@gmail.com/


Luca Leonardo Scorcia (7):
  dt-bindings: reset: Add mt6589 toprgu reset IDs
  watchdog: mediatek: Add wdt/toprgu resets for mt6589
  arm: dts: mediatek: mt6589: Enable toprgu reset controller
  dt-bindings: watchdog: Add compatible for MediaTek mt8167
  watchdog: mediatek: Add support for mt8167 toprgu/watchdog
  soc: mediatek: mtk-mmsys: Add resets for mt8167
  arm64: dts: mt8167: Properly describe the SoC watchdog and mmsys
    resets

 .../bindings/watchdog/mediatek,mtk-wdt.yaml   |  1 +
 arch/arm/boot/dts/mediatek/mt6589.dtsi        |  2 +
 arch/arm64/boot/dts/mediatek/mt8167.dtsi      | 10 ++++
 drivers/soc/mediatek/mt8167-mmsys.h           |  3 ++
 drivers/soc/mediatek/mtk-mmsys.c              | 38 +++++++++++++
 drivers/watchdog/mtk_wdt.c                    | 54 +++++++++++++++++--
 .../dt-bindings/reset/mediatek,mt6589-wdt.h   | 20 +++++++
 .../dt-bindings/reset/mediatek,mt8167-mmsys.h | 35 ++++++++++++
 .../dt-bindings/reset/mediatek,mt8167-wdt.h   | 21 ++++++++
 9 files changed, 179 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/reset/mediatek,mt6589-wdt.h
 create mode 100644 include/dt-bindings/reset/mediatek,mt8167-mmsys.h
 create mode 100644 include/dt-bindings/reset/mediatek,mt8167-wdt.h

-- 
2.43.0

Hi Luca,

On Wed, Aug 19, 2026 at 12:16:21PM +0200, Luca Leonardo Scorcia wrote:
> Currently mt8167 inherits its watchdog from the included mt8516 dtsi,
> which in turn falls back on mt6589-wdt, which does not support toprgu
> resets yet. This series adds support for mt6589 toprgu resets with bit
> definitions obtained from Android stock sources.
> 
> However, according to its data sheet, mt8167 has 14 sw resets instead of
> 12, and the reset bits are non-contiguous. This is currently unsupported
> by the mtk-wtd driver, and it caused confusion between reset IDs and reset
> bits in device tree includes.
> 
> Therefore in the first three patches we improve the description of the,
> resets for mt6589 using the definitions obtained from Android sources.
> 
> Then we introduce a dedicated mediatek,mt8167-wdt compatible for the
> watchdog driver that describes correctly this SoC's resets. Also while
> we're touching the bindings reset includes, we add IDs for the MMSYS
> resets.

This is somewhat outside the scope of this series, but adding TOPRGU
reset support for MT6589 exposes a pre-existing problem with the
mtk-wdt binding that I think should not go unnoticed.

Until now, using `mediatek,mt6589-wdt` as a fallback compatible for
other SoCs was mostly harmless, since the driver did not expose the
TOPRGU reset controller.
This series changes that by adding reset controller support for MT6589.

According to the MT6589 datasheet, its TOPRGU reset bits are:

  0 infra
  1 disp (same as mmsys in upstream)
  2 mfg
  3 venc
  4 vdec
  5 img
  6 ddrphy
  7 md
  8 infra_ao
  9 md_lite
 10 apmixed
 11 pwrap_spictl

These are the reset bits that `mediatek,mt6589-wdt` will provide once
this series is merged.
Therefore, for another SoC to use this compatible as a fallback,
its TOPRGU reset layout needs to be compatible with the above.

At commit bd5f485f3f02, mediatek,mtk-wdt.yaml contains:

      - 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

Let's examine the evidence for each of these SoCs.

## MT2701

I could not find enough public information to determine the reset
layout.


## MT6572

A downstream kernel suggests it has the same reset layout as MT6589:
https://github.com/orangepi-xunlong/OrangePi3G-iot_external/blob/b8a66e9bde91d75a8535dc6342d668efb6ab14ee/mediatek/platform/mt6572/kernel/core/include/mach/mt_wdt.h

However, a report based on actual hardware suggests
it may have fewer resets than MT6589:
https://lore.kernel.org/linux-mediatek/W7fWZU3pu6akI_HMTAWPGnnErv60QtTz-LaPb6OtGvU5Bx0Iekl4SxWB6mxBPx8cBo9q9Lg7t8dDzcyfti-5fTirEACcwCLhNAh8e5xoHus=@protonmail.com/

The datasheet is missing the bitfield for WDT_SWRST. 


## MT6582

According to the datasheet, the reset bits are:

  0 infra
  1 mm
  2 mfg
  4 vdec
  5 venc
  6 ddrphy
  7 md
  8 infra_ao
  9 conn
 10 apmixed
 12 conn_mcu

This is clearly not the same reset layout as MT6589.


## MT6797

According to the downstream kernel,
it has additional resets compared to MT6589:

  #define MTK_WDT_SWSYS_RST_C2KSYS_RST    (0x10000)
  #define MTK_WDT_SWSYS_RST_C2KWDT_RST    (0x20000)
  #define MTK_WDT_SWSYS_RST_CONMCU_RST    (0x1000)

https://github.com/SHIFTPHONES/android_kernel_shift_mt6797/blob/4c594e5fa5648dd9a8b8ccc5d609bb523f4799b7/drivers/watchdog/mediatek/wdt/mt6797/mt_wdt.h


## MT7622

According to the datasheet, the reset bits are:

  0 infra
  1 ethdma
  6 ddrphy
  8 infra_ao
  9 conn
 10 apmixed
 12 conn_mcu

This is not the MT6589 reset layout.


## MT7623

According to the datasheet, the reset bits are:

  0 infra
  1 mm
  2 mfg
  3 ethdma
  4 vdec
  5 venc_img
  6 ddrphy
  7 md
  8 infra_ao
  9 conn
 10 apmixed
 11 hifsys
 12 conn_mcu
 13 bdp_disp

Again, this is not the MT6589 reset layout.


## MT7629

I have no evidence either way. 


## MT8173

A the downstream kernel claims that MT8173 is compatible
with MT2701, MT8127 and MT8163:
https://github.com/bq/aquaris-M10/blob/ab0f5a519edaf314e9b537e448838ec9a4a9a3c8/drivers/watchdog/mediatek/wdt/common/mtk_wdt.c

I don't find this particularly convincing.

MT8163 has 15 reset bits:
https://github.com/amazon-oss/android_kernel_amazon_mt8163/blob/479f405abf2ee6c0f13688b8cf567cce135924af/include/dt-bindings/reset-controller/mt8163-resets.h

MT8127 appears to have the same reset layout as MT6589:
https://github.com/amazon-oss/android_kernel_amazon_mt8127/blob/8428ef2958b83fa51edd6de734c069455f00cd8b/arch/arm/mach-mt8127/include/mach/mt_wdt.h

However, I am not sure whether this actually reflects the hardware.


## MT8188

This is presumably a typo for MT8189, because there is no explanation
for using MT8188 in the patch:


[PATCH v7 6/9] dt-bindings: watchdog: Support MediaTek MT8189 wdt

modify dt-binding for support mt8189 dts node of wdt

Signed-off-by: Jack Hsu <jh.hsu@mediatek.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>

---
Changs in v7:
 - update dt-bindings commit msg
   (use "mt8189" instead of "mt8189 evb board")

---
 Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index ba0bfd73ab62..a05f8155b738 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -41,6 +41,7 @@ properties:
               - mediatek,mt7623-wdt
               - mediatek,mt7629-wdt
               - mediatek,mt8173-wdt
+              - mediatek,mt8188-wdt
               - mediatek,mt8365-wdt
               - mediatek,mt8516-wdt
           - const: mediatek,mt6589-wdt
-- 
2.45.2


https://lore.kernel.org/linux-arm-kernel/20251111070031.305281-7-jh.hsu@mediatek.com/
https://github.com/torvalds/linux/commit/a742d1713c34dff992d1273f614548d214ba1550
I honestly cannot understand how this passed review.

MT8188 already had a standalone compatible entry before this patch,
and it is clearly not compatible with MT6589:
https://github.com/torvalds/linux/blob/bd5f485f3f026225b86573e559af0b7254ef4184/include/dt-bindings/reset/mt8188-resets.h


## MT8189

There is no publicly available information about its reset layout:
https://github.com/external-mirrors/chromiumos-third_party-kernel/blob/a5153266e4c8777fac687e9009a12d32d946514b/drivers/watchdog/mtk_wdt.c#L462


## MT8365

I have no evidence to establish compatibility.


## MT8516

According to the downstream kernel, its reset layout appears to be
compatible with MT6589:
https://android.googlesource.com/platform/hardware/bsp/kernel/mediatek/mt8516-v4.4/+/refs/heads/nougat-iot-release/drivers/watchdog/mediatek/wdt/common/mtk_wdt.h


Note that a downstream kernel claiming compatibility does not necessarily
mean that the SoCs are actually compatible. In my experience, MediaTek's
downstream kernels contain substantial amounts of copied code between
different SoCs, so I would not consider such compatibility claims
sufficient evidence on their own.

Overall, I don't think `mediatek,mt6589-wdt` is an appropriate fallback
compatible for most of the SoCs currently listed in the binding.
I realize that fixing all of these bindings is outside the scope of
this series, but I think this should be addressed rather than leaving
`mediatek,mt6589-wdt` as a generic fallback.


I also noticed that the v3 link is missing from the cover letter:
[3] https://lore.kernel.org/linux-arm-kernel/20260809160643.33991-1-l.scorcia@gmail.com/

Best regards,
Akari

Hi Akari,
thank you for the detailed report!

> This is somewhat outside the scope of this series, but adding TOPRGU
> reset support for MT6589 exposes a pre-existing problem with the
> mtk-wdt binding that I think should not go unnoticed.
>
> Until now, using `mediatek,mt6589-wdt` as a fallback compatible for
> other SoCs was mostly harmless, since the driver did not expose the
> TOPRGU reset controller.
> This series changes that by adding reset controller support for MT6589.

This is the exact reason that led me to touching the MT6589 code. I
have been working on improving upstream support for MT8167 and its
TOPRGU reset is required for audio support, but the current fallback
on MT6589 does not allow resets. If I changed MT8167 only, a reviewer
might have thought that the new MT8167 resets should have been applied
to MT6589 instead.
This series should cause no regressions as the addition of
#reset-cells itself only registers the reset controller for
mt6589-derived boards and it does not trigger any reset on its own.

I agree that fixing MT6589 should be an initial step and that upstream
would greatly benefit from the cleanup you described. From a
high-level standpoint it seems like all of MediaTek's WDTs include a
sw reset controller, it's just that the reset table is different for
each SoC. If I'm not mistaken, fixing it shouldn't have particular
repercussions on existing ABI since the existing fallback could be
deprecated and their compatibles relisted as independent devices, i.e.
basically what I'm doing with MT8167.

> ## MT8516
>
> According to the downstream kernel, its reset layout appears to be
> compatible with MT6589:
> [...]
> Note that a downstream kernel claiming compatibility does not necessarily
> mean that the SoCs are actually compatible. In my experience, MediaTek's
> downstream kernels contain substantial amounts of copied code between
> different SoCs, so I would not consider such compatibility claims
> sufficient evidence on their own.

Kudos for finding MT8516 sources, I have been looking for them for
ages! They actually reinforce what you say above.
MT8167 hardware is currently described upstream as MT8516 + display
blocks, but the MT8167 resets as described in the data sheet are quite
different from MT6589. That said, I've also noticed that sometimes
parts of MediaTek's data sheets are copied from other SoCs too, and
sometimes contain mistakes of their own... unless it's possible to
test on an actual device, some kind of guessing is probably
inevitable.

> I also noticed that the v3 link is missing from the cover letter:
> [3] https://lore.kernel.org/linux-arm-kernel/20260809160643.33991-1-l.scorcia@gmail.com/

Thank you for spotting this, I will list it in the next iteration!
-- 
Luca Leonardo Scorcia
l.scorcia@gmail.com