diff options
| author | Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> | 2021-03-11 01:50:04 +0530 |
|---|---|---|
| committer | Wim Van Sebroeck <wim@linux-watchdog.org> | 2021-06-21 08:49:12 +0200 |
| commit | 8442ef6f11cf3efa2d5d2fbec5aef67368a8915b (patch) | |
| tree | 023dac2a6bccec59e1031ce0908a814bcf7960d6 /drivers/watchdog/qcom-wdt.c | |
| parent | bbfdad82efb30cae910b96b2cb4045812794c89d (diff) | |
watchdog: qcom: Move suspend/resume to suspend_late/resume_early
During suspend/resume usecases and tests, it is common to see issues
such as lockups either in suspend path or resume path because of the
bugs in the corresponding device driver pm handling code. In such cases,
it is important that watchdog is active to make sure that we either
receive a watchdog pretimeout notification or a bite causing reset
instead of a hang causing us to hard reset the machine.
There are good reasons as to why we need this because:
* We can have a watchdog pretimeout governor set to panic in which
case we can have a backtrace which would help identify the issue
with the particular driver and cause a normal reboot.
* Even in case where there is no pretimeout support, a watchdog
bite is still useful because some firmware has debug support to dump
CPU core context on watchdog bite for post-mortem analysis.
* One more usecase which comes to mind is of warm reboot. In case we
hard reset the target, a cold reboot could be induced resulting in
lose of ddr contents thereby losing all the debug info.
Currently, the watchdog pm callback just invokes the usual suspend
and resume callback which do not have any special ordering in the
sense that a watchdog can be suspended before the buggy device driver
suspend callback and watchdog resume can happen after the buggy device
driver resume callback. This would mean that the watchdog will not be
active when the buggy driver cause the lockups thereby hanging the
system. So to make sure this doesn't happen, move the watchdog pm to
use late/early system pm callbacks which will ensure that the watchdog
is suspended late and resumed early so that it can catch such issues.
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210310202004.1436-1-saiprakash.ranjan@codeaurora.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Diffstat (limited to 'drivers/watchdog/qcom-wdt.c')
| -rw-r--r-- | drivers/watchdog/qcom-wdt.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c index e38a87ffe5f5..0d2209c5eaca 100644 --- a/drivers/watchdog/qcom-wdt.c +++ b/drivers/watchdog/qcom-wdt.c @@ -329,7 +329,9 @@ static int __maybe_unused qcom_wdt_resume(struct device *dev) return 0; } -static SIMPLE_DEV_PM_OPS(qcom_wdt_pm_ops, qcom_wdt_suspend, qcom_wdt_resume); +static const struct dev_pm_ops qcom_wdt_pm_ops = { + SET_LATE_SYSTEM_SLEEP_PM_OPS(qcom_wdt_suspend, qcom_wdt_resume) +}; static const struct of_device_id qcom_wdt_of_table[] = { { .compatible = "qcom,kpss-timer", .data = &match_data_apcs_tmr }, |