drivers: wdt: npcx: add wdt driver support for npck3

[alvsun]

Enables the extended Watchdog Timer driver for npck3.

[fabiobaltieri]

This has the potential of creating an inconsistent situation if you'll ever have a chip with multiple watchdog timers, where the change in one of the compatibles result in a change in code for all the instances. Plus there's lot of boilerplate, would it make sense to use CONFIG_SOC_SERIES_NPCK3 instead?

[bjarki-andreasen]

There are two ways to do this in zephyr

a. Add a separate compatible, like "nuvoton,npcx-watchdog-npckn-v1", and use that as the primary and only compatible for the hardware. We don't have loadable drivers to choose from at runtime in order of specificity, the one driver included is the one you get, so only the one, specific compatible you will build a driver for, should be present.

b. add the extended feature as a flag, which seems like the way easiest solution here. add a boolean like is-extended; or supports-extended; or something to the binding for "nuvoton,npcx-watchdog", store the boolean in driver config, and check for it in the driver, no new Kconfig required :)

[fabiobaltieri]

yeah I second this, property seems the easier to maintain, but see my comment above, if this matches with some specific soc families it may be even simpler to use one of those options, ST does it all over the place (and to be perfectly honest the result is not pretty, but it works for them)

[alvsun]

Hi @fabiobaltieri @bjarki-andreasen
Thanks for the useful feedback.

We use a compatible-based approach to handle scenarios like the following:
For example, if a future NPCK5 series is designed to be compatible with NPCK3,
we can simply reuse the same compatible string in the DTS node to extend driver support, without modifying the existing driver logic.

This approach avoids adding additional conditional checks in Kconfig,
such as repeatedly updating WDT_NPCX_EX with new SoC series macros (e.g., CONFIG_SOC_SERIES_NPCK3 || CONFIG_SOC_SERIES_NPCK5),
which can become harder to maintain as more SoC series are introduced and may sometimes be unintentionally missed.

By leveraging the compatible mechanism, hardware inheritance and driver extension can be centralized in the device tree, keeping the driver code cleaner and reducing boilerplate.

As the number of supported variants grows, this design provides a more sustainable and scalable path for future maintenance and expansion.

Regarding the inconsistent situation that @fabiobaltieri mentioned,
We assume that the compatible string should be assigned to the same value for all instances of the same hardware module in a SoC. And they shouldn't be changed lightly.

If you have better suggestions or further concerns, please feel free to let me know.

[fabiobaltieri]

Yeah the suggestion is to add a boolean property instead of a new compatible, should be a way less intrusive change, especially if you have more variations in the future.

[alvsun]

For the boolean property, we have a couple of concerns and would appreciate your thoughts:

1. Code Size Impact:
   Since runtime boolean properties rely on runtime checks, the related code paths will always be included in the final binary.
   If we use compile-time #ifdefs (based on SoC configs), we can completely exclude unused code paths, which is critical for our resource-constrained platforms.
   Do you have any recommended practices to minimize code size increase when using runtime boolean properties?

2. Future Compatibility:
   If a future SoC (e.g., NPCK6) inherits features from both NPCK3 and NPCK5 while introducing additional unique functionalities, we would need to introduce more boolean flags to represent these new combinations, which may lead to increased complexity and harder maintenance.
   For example:
   supports-extended; for NPCK3 & NPCK5
   supports-extended-k6; for NPCK6
   Would you still recommend using the boolean flag approach for managing such evolving scenarios?

Note:
Since we have just started submitting the K3 PR, we plan to gradually submit other modules with minor changes (e.g., #89480, #90982) and gradually adopt this mechanism.

[ChiHuaL]

We also saw the similar usage in lpuart1 node of stm32 that assigns two compatible strings compatible = "st,stm32-lpuart", "st,stm32-uart"; in the compatible property and use the string st_stm32_lpuart to guard its specific codes in the driver.

[bjarki-andreasen]

1. we have DT_ANY_INST_HAS_PROP_STATUS_OKAY() to check if any device has the flag enabled and has status okay, so you can compile out the boolean if not needed :)
2. using separate, unique compats would be the way to go if its not the same hardware block with slight differences in features, but different hardware blocks. But its up to you which route you think matches best

[fabiobaltieri]

nit: wouldn't bother with the comment, the property name is descriptive enough

[alvsun]

Done

[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