From: "Martin Hundebøll" <martin@geanix.com>
To: Guenter Roeck <linux@roeck-us.net>,
Bruno Thomsen <bruno.thomsen@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-rtc@vger.kernel.org, linux-watchdog@vger.kernel.org
Subject: Re: [PATCHv2] rtc: pcf2127: handle boot-enabled watchdog feature
Date: Sun, 06 Oct 2019 17:58:01 +0200 [thread overview]
Message-ID: <CC1D25DB-F95B-4110-809C-E8BE1493CDB7@geanix.com> (raw)
In-Reply-To: <f741d1bd-bcde-d1e1-09b7-98bb6a30db33@roeck-us.net>
On 6 October 2019 16.29.45 CEST, Guenter Roeck <linux@roeck-us.net> wrote:
>On 10/6/19 2:07 AM, Bruno Thomsen wrote:
>> Hi Martin,
>>
>> Den tor. 3. okt. 2019 kl. 15.33 skrev Martin Hundebøll
><martin@geanix.com>:
>>>
>>> Linux should handle when the pcf2127 watchdog feature is enabled by
>the
>>> bootloader. This is done by checking the watchdog timer value during
>>> init, and set the WDOG_HW_RUNNING flag if the value differs from
>zero.
>>>
>>> Signed-off-by: Martin Hundebøll <martin@geanix.com>
>>> ---
>>>
>>> Change since v1:
>>> * remove setting of WDOG_HW_RUNNING in pcf2127_wdt_start()
>>>
>>> drivers/rtc/rtc-pcf2127.c | 12 +++++++++++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
>>> index cb3472f..4229915 100644
>>> --- a/drivers/rtc/rtc-pcf2127.c
>>> +++ b/drivers/rtc/rtc-pcf2127.c
>>> @@ -420,6 +420,7 @@ static int pcf2127_probe(struct device *dev,
>struct regmap *regmap,
>>> const char *name, bool has_nvmem)
>>> {
>>> struct pcf2127 *pcf2127;
>>> + u32 wdd_timeout;
>>> int ret = 0;
>>>
>>> dev_dbg(dev, "%s\n", __func__);
>>> @@ -462,7 +463,6 @@ static int pcf2127_probe(struct device *dev,
>struct regmap *regmap,
>>> /*
>>> * Watchdog timer enabled and reset pin /RST activated when
>timed out.
>>> * Select 1Hz clock source for watchdog timer.
>>> - * Timer is not started until WD_VAL is loaded with a valid
>value.
>>
>> Your patch does not change the fact that the watchdog timer is first
>> started after loading a
>> valid value into WD_VAL register. This driver can be used perfectly
>> fine without enabling the
>> watchdog feature from userspace. If someone chooses to reboot without
>> stopping the watchdog
>> it is of course expected to still run on next boot (e.g. device
>probe).
>>
>>> + /* Test if watchdog timer is started by bootloader */
>>> + ret = regmap_read(pcf2127->regmap, PCF2127_REG_WD_VAL,
>&wdd_timeout);
>>> + if (ret) {
>>> + dev_err(dev, "%s: watchdog value (wd_wal) failed\n",
>__func__);
>>> + return ret;
>>> + }
>>> +
>>> + if (wdd_timeout)
>>> + set_bit(WDOG_HW_RUNNING, &pcf2127->wdd.status);
>>> +
>>
>> I do not agree that this should be the default setting as
>> WDOG_HW_RUNNING bit causes
>> watchdog core to kick watchdog until userland takes over, e.g. you
>> have just broken the
>> chain-of-monitoring in the embedded Linux device:
>>
>> Hardware watchdog -> systemd -> daemon(s) / application(s)
>>
>> At this point in time you only know that u-boot / barebox can load
>and
>> start the kernel with
>> a device tree blob.
>>
>> What if mounting of rootfs fails?
>> What if systemd fails to start?
>>
>> When doing a reboot due to ex. firmware upgrade, systemd will keep
>> kicking the watchdog
>> until the last sec before restart handler is called and the hardware
>> watchdog should not be
>> touched before systemd is in control of the system again.
>>
> > Bruno
> >
>
>This should not be decided on driver level. The intended means to
>enforce
>an initial timeout would be to set CONFIG_WATCHDOG_OPEN_TIMEOUT, or to
>use
>the open_timeout kernel parameter.
That, and WATCHDOG_HANDLE_BOOT_ENABLED
// Martin
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2019-10-06 15:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 12:48 [PATCH] rtc: pcf2127: handle boot-enabled watchdog feature Martin Hundebøll
2019-10-03 13:05 ` Guenter Roeck
2019-10-03 13:27 ` Martin Hundebøll
2019-10-03 13:56 ` Guenter Roeck
2019-10-03 13:33 ` [PATCHv2] " Martin Hundebøll
2019-10-03 13:57 ` Guenter Roeck
2019-10-03 21:44 ` Alexandre Belloni
2019-10-06 9:07 ` Bruno Thomsen
2019-10-06 14:29 ` Guenter Roeck
2019-10-06 15:58 ` Martin Hundebøll [this message]
2019-10-06 16:19 ` Guenter Roeck
2019-10-07 10:49 ` Bruno Thomsen
2019-10-07 12:31 ` Guenter Roeck
2019-10-21 8:08 ` [PATCHv3] " Martin Hundebøll
2019-10-21 8:33 ` Alexandre Belloni
2019-10-21 16:12 ` 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=CC1D25DB-F95B-4110-809C-E8BE1493CDB7@geanix.com \
--to=martin@geanix.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bruno.thomsen@gmail.com \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
/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;
as well as URLs for NNTP newsgroup(s).