[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131002204217.GA14148@roeck-us.net>
Date: Wed, 2 Oct 2013 13:42:17 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: boris brezillon <b.brezillon@...rkiz.com>
Cc: Wim Van Sebroeck <wim@...ana.be>,
Nicolas Ferre <nicolas.ferre@...el.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Ludovic Desroches <ludovic.desroches@...el.com>,
Yang Wenyou <Wenyou.Yang@...el.com>,
linux-watchdog@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [v2,1/4] watchdog: at91sam9_wdt: better watchdog support
On Wed, Oct 02, 2013 at 09:53:54PM +0200, boris brezillon wrote:
[ ... ]
> >>>>+
> >>>>+ if (!wdt->heartbeat) {
> >>>>+ dev_err(wdt->wdd.parent,
> >>>>+ ": sorry, linux timer (%i Hz) cannot handle watchdog timeout (%i ms)\n",
> >>>>+ HZ, ticks_to_ms(value));
> >>>>+ return -EINVAL;
> >>>Isn't that a bit rude ? Why not set it to the minimum ?
>
> I might have misunderstood your point.
> What is a bit rude ?
> - the fact that the minimum heartbeat timeout has to be at less or
> equal to one-forth of
> max heartbeat timeout
> - the fact that heartbeat expressed in ticks has to be more than 0
> - something else
That you don't auto-correct the heatbeat to the minimum but return -EINVAL instead.
I prefer to be user-friendly, which in this case would be to accept and handle
the <min, max> timeout values provided to the infrastructure and handle any
deviations / limitaions internally.
Or, in other words, I don't like it if the user ends up having to guess
valid parameter ranges.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists