drivers: watchdog: wdt_xilinx_wwdt: cleanup, firmware-owned reset, DEVICE_MMIO, zero-window fix

[Harini-T]

Summary

This series cleans up the Xilinx Versal Window Watchdog (WWDT) driver: drops an unused include, corrects reset-flag handling to reflect the platform's firmware-owned reset model, converts register access to the DEVICE_MMIO API, and fixes a zero-max-window validation gap. The changes are backward compatible: existing device tree nodes that provide reg/clocks continue to work unchanged, and there is no new required property or Kconfig option.

Commits

1. drop unused hwinfo include — the driver never used the hwinfo API; remove the stray include.
2. do not gate install on reset flags — the expiry/reset action (no reset, CPU/subsystem reset, or SoC reset) is routed through the Error Aggregation Module and configured by the PLM via the boot-time CDO. Zephyr on the APU/RPU can neither observe nor change that routing, so the driver cannot honor any WDT_FLAG_RESET_* value (including
   WDT_FLAG_RESET_NONE). Stop rejecting non-WDT_FLAG_RESET_SOC flags; accept the timeout regardless and warn at install time that the flag has no effect. The firmware-owned reset behavior is documented in the binding.
3. use DEVICE_MMIO for register access — store the register region with the DEVICE_MMIO ROM/RAM helpers and access it via DEVICE_MMIO_GET(). On MMU targets (aarch64 APU) the region is mapped dynamically via device_map(); on non-MMU targets (R52 RPU) it reduces to direct physical access, so behavior is unchanged there.
4. reject zero max window — wdt_install_timeout() accepted window.max == 0, programming a zero timeout and returning success; reject it with -EINVAL.

[kedareswararao]

Changes looks fine to me

[Harini-T]

Force-pushed: rebased and extended the series since the last review. Changes:

• New commit — "reject zero max window" (inserted before the interrupt commit): fixes a
  pre-existing gap where wdt_install_timeout() accepted window.max == 0 and returned success
  instead of -EINVAL. Placed early so every later commit builds on correct validation. Surfaced by
  tests/drivers/watchdog/wdt_basic_reset_none::test_wdt_bad_window_max.
• New commit — "add generic watchdog (GWDT) support": adds the IP's second engine behind a
  Kconfig choice (window mode remains default). New file touched: Kconfig.xilinx_wwdt.
• The reset-flags warning is now gated on cfg->flags != WDT_FLAG_RESET_NONE, so it no longer fires
  on every install for the common RESET_NONE case.
• Rest of the series is unchanged in intent; only rebase context shifted.
  Tested on Versal (APU) and Versal NET (RPU) across all four combinations — WWDT and GWDT, each with
  and without the interrupt wired: install/setup/feed for the no-interrupt cases, and the
  warning-callback path (feed-from-callback) for the interrupt cases; test_wdt_bad_window_max and
  test_wdt_callback_reset_none pass.

[kedareswararao]

After this series the umbrella symbol XILINX_WINDOW_WATCHDOG also enables the
generic watchdog engine (via the new mode choice), yet the prompt and help text describe only
the window watchdog. A reader enabling GWDT still has to turn on a symbol literally named "window
watchdog", which is confusing.

[Harini-T]

Agreed, Shall i rename the symbol to XILINX_VERSAL_WATCHDOG or reword the help only ?

[kedareswararao]

If the code is Vearl specific rename else update the help menu

[Harini-T]

I'll rename the umbrella symbol to XILINX_VERSAL_WATCHDOG and update the prompt/help to describe the Versal watchdog IP (both WWDT and GWDT engines). The mode choice underneath stays as-is; window mode remains the default.

[kedareswararao]

The engine is chosen at build time via a mutually-exclusive choice, so a single
image can drive only one engine even though the IP exposes both WWDT and GWDT concurrently (and a
system could legitimately want the window watchdog on one instance and the generic watchdog on
another). XWWDT_IRQ_NAME, the mode branches, and the BUILD_ASSERT all key off this global
choice, so it also applies uniformly to every instance of the compatible

Is a global build-time choice sufficient for the target products, or should the
engine be selectable per-node (e.g. a DT property / distinct compatible) so both engines can be used
in one image?

[Harini-T]

A global build-time choice is sufficient for our target platforms. On Versal, which engine can trigger a PMC reset is fixed by the hardware design and the PLM boot-time CDO — not selectable at runtime. On most Versal boards, WWDT expiry is routed to the PMC via the CDO; GWDT is typically not. On a smaller set of designs, only GWDT is wired to the PMC for reset.
So each board/product uses one engine for platform reset, and that same choice applies to all xlnx,versal-wwdt instances in the image. A mutually exclusive Kconfig choice matches that integration model. I don't have a use case for mixed WWDT/GWDT reset routing across instances in one image; we can add per-node selection in a follow-up if a concrete product need appears.

[zephyrbot]

@venodela

You have been identified as a likely reviewer for the code this pull request changes, but could not be added to its review request automatically. Please review it if you are able to.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kedareswararao]

XILINX_WINDOW_WATCHDOG was released in v4.3.0 (driver added in
e343379510f1, v4.3.0-rc1~7233). This series renames it to XILINX_VERSAL_WATCHDOG on the
4.4 development branch (current VERSION = 4.4.99) with no release-notes / migration-guide
entry and no deprecated alias. Downstream configs that set CONFIG_XILINX_WINDOW_WATCHDOG=…
will silently stop resolving after upgrade.

Add a doc/releases/release-notes-4.4.rst (and/or migration guide) entry noting the
rename XILINX_WINDOW_WATCHDOG → XILINX_VERSAL_WATCHDOG. Practical impact is low because the
symbol is default y and gated on `DT_HAS_XLNX_VERSAL_WWDT_ENABLED

[kedareswararao]

And also this commit bundles three distinct changes: (a) a pure refactor that extracts the
existing window logic into wdt_xilinx_wwdt_install_window() and wraps setup/feed/
disable/isr in IS_ENABLED(...WINDOW_MODE) branches, (b) the new GWDT feature, and
(c) the Kconfig symbol rename. Mixing a behavior-preserving refactor with a new feature and a
rename in one 362-line commit makes review and bisection harder.

Consider splitting: one commit that refactors the window path into per-mode helpers
(no behavior change), then a commit that adds GWDT + the Kconfig choice/rename.

[Harini-T]

Scope update: I've dropped the final two commits (WINT interrupt callback and generic watchdog / GWDT support) and force-pushed. The series is now limited to the WWDT cleanup and fixes: drop unused include, firmware-owned reset handling, DEVICE_MMIO conversion, and zero-max-window rejection.

Rationale:

• GWDT is a distinct engine with different semantics and platform scope. It will be maintained as a separate driver with its own compatible string rather than added here behind a build-time mode choice.
• The WINT interrupt path primarily supported the GWDT flow; on WWDT the interrupt fires at open-window entry rather than expiry, which does not match the generic pre-reset callback contract. With GWDT out of scope, it is removed as well.
  The upstream driver stays focused on WWDT with no new Kconfig options or required DT properties. Title and description updated accordingly.