All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Douglas Anderson <dianders@chromium.org>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	linux-watchdog@vger.kernel.org,
	Stephen Boyd <swboyd@chromium.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Guenter Roeck <groeck7@gmail.com>
Subject: Re: [PATCH] watchdog: qcom: Move suspend/resume to suspend_late/resume_early
Date: Mon, 24 May 2021 09:42:09 +0530	[thread overview]
Message-ID: <ada92dd88c775b5140c397d4cef74f83@codeaurora.org> (raw)
In-Reply-To: <3f76d6cc-df32-6bf3-9971-4ca8f0ee8169@roeck-us.net>

On 2021-05-24 09:33, Guenter Roeck wrote:
> On 5/23/21 7:38 PM, Sai Prakash Ranjan wrote:
>> On 2021-04-20 11:13, Sai Prakash Ranjan wrote:
>>> Hi Guenter,
>>> 
>>> On 2021-03-11 01:53, Guenter Roeck wrote:
>>>> On Thu, Mar 11, 2021 at 01:50:04AM +0530, Sai Prakash Ranjan wrote:
>>>>> 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>
>>>> 
>>> 
>>> Gentle Ping. I don't see this in linux-next or linux-watchdog, please 
>>> let
>>> me know if anything is pending from my side.
>>> 
>> 
>> Gentle Ping !!
>> 
> 
> It is my watchdog-next branch. At some point Wim will hopefully pick it 
> up.
> 

Ah I see, thanks for the info.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2021-05-24  4:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 20:20 [PATCH] watchdog: qcom: Move suspend/resume to suspend_late/resume_early Sai Prakash Ranjan
2021-03-10 20:23 ` Guenter Roeck
2021-03-10 20:23   ` Guenter Roeck
2021-04-20  5:43   ` Sai Prakash Ranjan
2021-05-24  2:38     ` Sai Prakash Ranjan
2021-05-24  4:03       ` Guenter Roeck
2021-05-24  4:03         ` Guenter Roeck
2021-05-24  4:12         ` Sai Prakash Ranjan [this message]
2021-03-10 20:27 ` Doug Anderson
2021-03-10 20:27   ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ada92dd88c775b5140c397d4cef74f83@codeaurora.org \
    --to=saiprakash.ranjan@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=groeck7@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mka@chromium.org \
    --cc=swboyd@chromium.org \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.