All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Guenter Roeck <linux@roeck-us.net>, Wim Van Sebroeck <wim@iguana.be>
Cc: <linux-watchdog@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_DEADLINE
Date: Thu, 21 Jul 2016 00:08:52 +0200	[thread overview]
Message-ID: <578FF674.2000704@prevas.dk> (raw)
In-Reply-To: <5788F34E.8060905@roeck-us.net>

On 2016-07-15 16:29, Guenter Roeck wrote:
> On 07/15/2016 12:32 AM, Rasmus Villemoes wrote:
>
>>> The initial timeout should be specified as module option or as
>>> devicetree parameter, and there should be no additional configuration
>>> option.
>>
>> I was under the impression that device tree was exclusively for
>> describing hardware, and this certainly is not that. I also wanted to
>> avoid having to modify each driver, which would seem to be necessary
>> if it was module parameter/DT - the only thing required of a driver
>> now is that it correctly reports WDOG_HW_RUNNING.
>
> What is "hardware" ? It is supposed to describe the system, isn't it ?
> Part of that system is its clock rate,
> and the means how the OS is loaded, and both have impact on the initial
> timeout (and the regular timeout).
>
> You might as well argue that clock rates should not be in devicetree
> either. Clock rates are, after all,
> just reflecting the _use_ of the hardware, not the hardware itself.

But they are used to configure hardware. The init timeout is not a 
property of any particular device - it configures how the kernel 
behaves, and as such I find it quite natural to have it in the kernel's 
.config (and overridable on command line and via sysfs).

> Devicetree could be handled in the core, with a function to set the
> initial timeout,
> or possibly even with the watchdog registration itself.

But where in the device tree would you put this value? I'd really prefer 
not having to modify the node representing each individual watchdog 
device I might use.

Rasmus

  reply	other threads:[~2016-07-20 22:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14  9:16 [RFC 0/3] watchdog: introduce open deadline Rasmus Villemoes
2016-07-14  9:16 ` [RFC 1/3] watchdog: change watchdog_need_worker logic Rasmus Villemoes
2016-07-14 20:45   ` Guenter Roeck
2016-07-17 19:24   ` Wim Van Sebroeck
2016-07-17 19:49     ` Guenter Roeck
2016-07-17 20:30       ` Wim Van Sebroeck
2016-07-17 20:33   ` Wim Van Sebroeck
2016-07-14  9:16 ` [RFC 2/3] watchdog: introduce watchdog_worker_should_ping helper Rasmus Villemoes
2016-07-14  9:16 ` [RFC 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_DEADLINE Rasmus Villemoes
2016-07-14 14:42   ` Guenter Roeck
2016-07-15  7:32     ` Rasmus Villemoes
2016-07-15 14:29       ` Guenter Roeck
2016-07-20 22:08         ` Rasmus Villemoes [this message]
2016-07-21  0:31           ` Guenter Roeck
2016-07-27 20:17             ` Rasmus Villemoes
2016-07-31 22:17               ` Guenter Roeck
2016-08-01 11:10                 ` Wim Van Sebroeck
2016-12-12  9:17 ` [PATCH v2 0/2] watchdog: allow setting deadline for opening /dev/watchdogN Rasmus Villemoes
2016-12-12  9:17   ` [PATCH v2 1/2] watchdog: introduce watchdog_worker_should_ping helper Rasmus Villemoes
2016-12-12  9:17   ` [PATCH v2 2/2] watchdog: introduce CONFIG_WATCHDOG_OPEN_DEADLINE Rasmus Villemoes
2016-12-12 16:59     ` Guenter Roeck
2016-12-14 13:37   ` [PATCH v3 0/2] watchdog: allow setting deadline for opening /dev/watchdogN Rasmus Villemoes
2016-12-14 13:37     ` [PATCH v3 1/2] watchdog: introduce watchdog_worker_should_ping helper Rasmus Villemoes
2016-12-14 13:37     ` [PATCH v3 2/2] watchdog: introduce CONFIG_WATCHDOG_OPEN_TIMEOUT Rasmus Villemoes
2017-01-02 15:22       ` Guenter Roeck
2017-01-03 15:52         ` Rasmus Villemoes
2017-01-03 18:59           ` Guenter Roeck
2017-01-02  8:04     ` [PATCH v3 0/2] watchdog: allow setting deadline for opening /dev/watchdogN Rasmus Villemoes

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=578FF674.2000704@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=wim@iguana.be \
    /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.