devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
To: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Detlev Zundel <dzu-ynQEQJNshbs@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>,
	Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
Subject: Re: [PATCH] RFC, watchdog: add generic wdt driver API
Date: Wed, 07 Dec 2011 07:37:18 +0100	[thread overview]
Message-ID: <4EDF099E.80207@denx.de> (raw)
In-Reply-To: <20111205122649.6fc6aed2-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>

Hello Alan,

Alan Cox wrote:
>> that we have a number of customers who consider the existing wdt
>> support unsufficient for their use cases.  We've been using it on all
>> kinds on PPC systems, and now on ARM as well.
>>
>> We will not fight for inclusion of this driver, we just wat to know if
>> it's worth investing efforts to get it accepted or if this is a lost
>> case.
> 
> I think it would be better to start from the needed feature list than the
> implementation of an old and wildly different pile of code. Then discuss
> adding those features that are relevant to the current framework - which
> ought to be relatively easy now each watchdog is a set of methods.

Ok, I try to describe the needed new features called in the old
driver code Chain API:

  The chain API is used to register configurable "watchdog chains" from
  either user or kernel space.  A watchdog chain is identified by an
  unsigned integer and can contain up to three action stages. Configured
  through ioctl().

  A "time interval" in seconds and an "action" is associated with each
  stage.  When the chain is not reset before the interval elapses, the
  associated action is triggered and the chain moves on to the next stage.

  A chain can request to kill the registering process if the interval
  elapses.  In this case a restarted process can register with the
  driver giving the same identifier and reset the chain.  This is the
  main reason why there is no association between chains and processes
  or open device files.

  Possible chain actions:
  - ACTION_SIGNAL: sends a configurable signal to the process
  - ACTION_KILL: sends the SIGKILL signal to the process
  - ACTION_REBOOT: tries a soft reboot
  - ACTION_RESET: triggers a hard-reset

  ioctl calls:
  - WD_REGISTER: register a chain

    The parameter given to the call is a pointer to a structure with
    the following layout:

    struct wd_param {
      unsigned chainid;
      unsigned long timer_count[3];
      int action[3];
      int signal;
    } wd_param;

    Each stage is configured with entries in the arrays "timer_count"
    and "action."

    The timer_count contains the length of the interval in seconds
    while action contains one of the above described ACTION_* constants.

    A timer_count of zero signals the end of the chain.

  - WD_RESET:
    This call resets the chain denoted by the unsigned integer
    passed to it.  When reset, a chain will expire beginning with
    stage zero again.

  - WD_UNREGISTER:
    As closing the device file will not have any effect on chains,
    a process must unregister a chain if the service is no longer
    needed. This can be done with this ioctl taking an unsigned
    integer as a parameter denoting the chain with the same chainid
    to be unregistered.

Has such a framework a chance to go in mainline? What would be a good
starting point to integrate it? As this "chain API" would controlled
through ioctl() calls maybe drivers/watchdog/watchdog_dev.c would be
a good place... or a drivers/watchdog/watchdog_chain.c which gets the
ioctl calls, watchdog_dev.c couldn't parse ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  parent reply	other threads:[~2011-12-07  6:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-04  9:53 [PATCH] RFC, watchdog: add generic wdt driver API Heiko Schocher
2011-12-04 12:59 ` Wolfram Sang
2011-12-04 17:08   ` Wolfgang Denk
     [not found]     ` <20111204170810.8370625EA22-C2Gvrrd9BC/j/ljBK/0BTg@public.gmane.org>
2011-12-05 12:26       ` Alan Cox
     [not found]         ` <20111205122649.6fc6aed2-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
2011-12-07  6:37           ` Heiko Schocher [this message]
     [not found]             ` <4EDF099E.80207-ynQEQJNshbs@public.gmane.org>
2011-12-07 17:23               ` Alan Cox
2011-12-06 21:59     ` Wolfram Sang

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=4EDF099E.80207@denx.de \
    --to=hs-ynqeqjnshbs@public.gmane.org \
    --cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=dzu-ynQEQJNshbs@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sr-ynQEQJNshbs@public.gmane.org \
    --cc=wd-ynQEQJNshbs@public.gmane.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 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).