Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WDT_DISABLE_AT_BOOT, if enabled by default, degrades functionality of the watchdog #22858

Closed
mnkp opened this issue Feb 16, 2020 · 0 comments · Fixed by #22859
Closed

WDT_DISABLE_AT_BOOT, if enabled by default, degrades functionality of the watchdog #22858

mnkp opened this issue Feb 16, 2020 · 0 comments · Fixed by #22859
Assignees
Labels
area: Watchdog Watchdog bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Milestone

Comments

@mnkp
Copy link
Member

mnkp commented Feb 16, 2020

#21142 made WDT_DISABLE_AT_BOOT option default to y.

Motivation behind the PR was to enforce the consistent default behavior of the watchdog to be "disabled by default until explicitly enabled by the application." However, this approach is wrong. There is a very good reason why some vendors start the watchdog automatically upon reset: the code can hang during the boot process before the software has a chance to configure it.

There are several other major issues with having WDT_DISABLE_AT_BOOT enabled by default.

  • it's a relatively common feature among different watchdog implementations that the module can be configured only once upon boot. Unless the user explicitly sets WDT_DISABLE_AT_BOOT to n the watchdog subsystem will be disabled for good. Any code that wants to be portable will always need to explicitly set WDT_DISABLE_AT_BOOT to n.
  • watchdog that can be re-programmed and was started automatically upon reset will be temporarily disabled. The option is easy to overlook and this defective behavior is unlikely to be caught by a testcase. Unless the user explicitly sets WDT_DISABLE_AT_BOOT to n the functionality of the watchdog subsystem will be degraded.
  • there are already users who configured their watchdog subsystem and didn't set WDT_DISABLE_AT_BOOT to n. If they happen to have a watchdog module that can be configured only once, e.g. Atmel SAM family, this PR effectively - and quietly - disables their watchdog subsystem. Some of them may not have a testcase that will catch the issue.

Having WDT_DISABLE_AT_BOOT set to y makes it easy for us to maintain samples and testcases since we almost never want the watchdog to be enabled (apart from the watchdog testcase). However, in production environment the opposite is true.

To fix the issue reported in #21025 we can set the option to y in a board Kconfig.defconfig file. It's more work for us since we need to modify every evaluation board that is starting the watchdog automatically but it saves extra work and frustration for Zephyr users.

@mnkp mnkp added bug The issue is a bug, or the PR is fixing a bug area: Watchdog Watchdog labels Feb 16, 2020
@mnkp mnkp added this to the v2.2.0 milestone Feb 16, 2020
@mnkp mnkp linked a pull request Feb 16, 2020 that will close this issue
@mnkp mnkp added has-pr priority: medium Medium impact/importance bug labels Feb 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Watchdog Watchdog bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant