From: Guenter Roeck <linux@roeck-us.net>
To: "Freddy.Hsin" <freddy.hsin@mediatek.com>
Cc: "Wim Van Sebroeck" <wim@linux-watchdog.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
wsd_upstream <wsd_upstream@mediatek.com>,
"Chang-An Chen (陳昶安)" <Chang-An.Chen@mediatek.com>,
"Kuohong Wang (王國鴻)" <kuohong.wang@mediatek.com>
Subject: Re: [PATCH v1 1/1] driver: watchdog: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem
Date: Tue, 29 Dec 2020 07:08:28 -0800 [thread overview]
Message-ID: <01d27a27-4dd7-8ffb-cc00-81def958f659@roeck-us.net> (raw)
In-Reply-To: <1609231194.9252.6.camel@mtkswgap22>
On 12/29/20 12:39 AM, Freddy.Hsin wrote:
> On Fri, 2020-12-25 at 22:27 +0800, Guenter Roeck wrote:
>> On 12/24/20 11:30 PM, Freddy Hsin wrote:
>>> From: "freddy.hsin" <freddy.hsin@mediatek.com>
>>>
>>> Before user space daemon start to access the watchdog device,
>>> there is a time interval that watchdog is disabled in the
>>> original flow. If the system freezing at this interval, it
>>> cannot be rebooted by watchdog hardware automatically.
>>>
>>> In order to solve this problem, the watchdog hardware should be
>>> kept working, and start hrtimer in framework to ping it by
>>> setting max_hw_heartbeat_ms and HW_RUNNING used in
>>> watchdog_need_worker to determine whether the worker should be
>>> started or not
>>>
>>> Change-Id: I6a041b0922888a90011d7538ee804d80bc8d15ea
>>> Signed-off-by: freddy.hsin <freddy.hsin@mediatek.com>
>>> ---
>>> drivers/watchdog/mtk_wdt.c | 22 ++++++++++++++++++----
>>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>> index d6a6393..62f08cd 100644
>>> --- a/drivers/watchdog/mtk_wdt.c
>>> +++ b/drivers/watchdog/mtk_wdt.c
>>> @@ -195,6 +195,19 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>> return 0;
>>> }
>>>
>>> +static void mtk_wdt_init(struct watchdog_device *wdt_dev)
>>> +{
>>> + struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>> + void __iomem *wdt_base;
>>> +
>>> + wdt_base = mtk_wdt->wdt_base;
>>> +
>>> + if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) {
>>> + set_bit(WDOG_HW_RUNNING, &wdt_dev->status);
>>> + mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>>> + }
>>> +}
>>> +
>>> static int mtk_wdt_stop(struct watchdog_device *wdt_dev)
>>> {
>>> struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>> @@ -266,16 +279,17 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>> mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>>> mtk_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
>>
>> No longer needed if max_hw_heartbeat_ms is set.
>
> Got it. it will be removed in V2 patch
>
>>
>>> mtk_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
>>> + mtk_wdt->wdt_dev.max_hw_heartbeat_ms = (WDT_MAX_TIMEOUT - 1) * 1000;
>>
>> This needs explanation. Why WDT_MAX_TIMEOUT - 1 ?
>
> In watchdog_need_worker(), there is a condition for starting worker (hm
> && watchdog_active(wdd) && t > hm), so I think in the case
> that watchdog_active is true, the t (timeout) should be greater than
> hm (max_hw_heartbeat_ms) or the worker will not work. Shouldn't I
> consider for this case?
>
You are claiming that the watchdog core is buggy. Make your case there, not here.
Guenter
>>
>>> mtk_wdt->wdt_dev.parent = dev;
>>>
>>> + watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
>>> +
>>> + mtk_wdt_init(&mtk_wdt->wdt_dev);
>>> +
>>
>> Setting the chip (with the maximum timeout) ...
>>
> Got it. mtk_wdt_init will be moved after watchdog_init_timeout in V2
>
> BRs,
> FreddyHsin
>
>>> watchdog_init_timeout(&mtk_wdt->wdt_dev, timeout, dev);
>>
>> just before initializing/setting the real timeout doesn't really make sense.
>>
>>> watchdog_set_nowayout(&mtk_wdt->wdt_dev, nowayout);
>>> watchdog_set_restart_priority(&mtk_wdt->wdt_dev, 128);
>>>
>>> - watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
>>> -
>>> - mtk_wdt_stop(&mtk_wdt->wdt_dev);
>>> -
>>> watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
>>> err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
>>> if (unlikely(err))
>>>
>>
>
next prev parent reply other threads:[~2020-12-29 15:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-25 7:30 Freddy Hsin
2020-12-25 7:30 ` [PATCH v1 1/1] " Freddy Hsin
2020-12-25 14:27 ` Guenter Roeck
[not found] ` <1609231194.9252.6.camel@mtkswgap22>
2020-12-29 15:08 ` Guenter Roeck [this message]
2020-12-25 14:29 ` Guenter Roeck
2020-12-25 14:27 ` Guenter Roeck
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=01d27a27-4dd7-8ffb-cc00-81def958f659@roeck-us.net \
--to=linux@roeck-us.net \
--cc=Chang-An.Chen@mediatek.com \
--cc=freddy.hsin@mediatek.com \
--cc=kuohong.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=wim@linux-watchdog.org \
--cc=wsd_upstream@mediatek.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®