All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: linux-watchdog@vger.kernel.org, Martin Wilck <mwilck@suse.com>,
	Wim Van Sebroeck <wim@linux-watchdog.org>,
	Guenter Roeck <linux@roeck-us.net>
Cc: Giel van Schijndel <me@mortis.eu>,
	"Steven J. Hill" <Steven.Hill@cavium.com>
Subject: Default behavior of watchdog drivers
Date: Thu, 27 Sep 2018 14:38:55 +0200	[thread overview]
Message-ID: <20180927143855.6f8cc48e@endymion> (raw)

Hello,

It seems that various watchdog drivers behave differently if the
watchdog timer is already enabled when the driver is loaded:

* iTCO_wdt will disable the timer. I think this is what most drivers
  do, but not all.
* w83627hf_wdt will let the timer run, unless option early_disable=1 is
  passed.

These are the 2 which bother me the most because they are among the
most popular watchdog drivers on x86 systems. Having a different
behavior depending on which driver is used is quite confusing.

Can we please settle on a default behavior (either all drivers reset
the timer a load time, or none do it) and have all watchdog drivers
stick to that?

If an option to get the opposite behavior is deemed useful, can we
settle on a standard name for it? Or even implement it at the
watchdog_core level, so that each driver doesn't need to implement it
separately?

While looking into this, I found a few other strange module parameters:

* f71808e_wdt has "start_withtimeout", which starts the timer even if
  nobody opens the watchdog device node. Giel, do we really need this?
* octeon-wdt has "disable", which completely disables the watchdog
  function. This "feature" was sneaked in via commit 381cec022e46
  ("watchdog: octeon-wdt: File cleaning.") which was supposed to be a
  cleanup-only patch, without any explanation nor even mention. I can't
  see how such an option can be useful. If you don't need the driver,
  just don't load it. Steven, can you explain?

Thanks,
-- 
Jean Delvare
SUSE L3 Support

             reply	other threads:[~2018-09-27 12:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-27 12:38 Jean Delvare [this message]
2018-09-27 13:08 ` Default behavior of watchdog drivers Guenter Roeck
2018-10-01 11:36   ` Giel van Schijndel
  -- strict thread matches above, loose matches on Subject: below --
2018-09-30 13:09 Wim Van Sebroeck
2018-09-30 13:58 ` Guenter Roeck
2018-10-02 11:39   ` Wim Van Sebroeck
2018-10-02 13:24     ` 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=20180927143855.6f8cc48e@endymion \
    --to=jdelvare@suse.de \
    --cc=Steven.Hill@cavium.com \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=me@mortis.eu \
    --cc=mwilck@suse.com \
    --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.