linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "Bruno Thomsen" <bruno.thomsen@gmail.com>,
	"Martin Hundebøll" <martin@geanix.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, 6 Oct 2019 07:29:45 -0700	[thread overview]
Message-ID: <f741d1bd-bcde-d1e1-09b7-98bb6a30db33@roeck-us.net> (raw)
In-Reply-To: <CAH+2xPAtxcxd1xXuCmHc25X-Ai2_w-5rxZrgYbavjAzntMxX-Q@mail.gmail.com>

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.

Guenter

  reply	other threads:[~2019-10-06 14:29 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 [this message]
2019-10-06 15:58       ` Martin Hundebøll
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=f741d1bd-bcde-d1e1-09b7-98bb6a30db33@roeck-us.net \
    --to=linux@roeck-us.net \
    --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=martin@geanix.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;
as well as URLs for NNTP newsgroup(s).