Hi Uwe,
On 08/04/2015 08:41 AM, Uwe Kleine-König wrote:
Hello,
On Mon, Aug 03, 2015 at 07:13:29PM -0700, Guenter Roeck wrote:
The WDOG_RUNNING flag is expected to be set by watchdog drivers if
the hardware watchdog is running. If the flag is set, the watchdog
subsystem will ping the watchdog even if the watchdog device is closed.
The watchdog driver stop function is now optional and may be omitted
if the watchdog can not be stopped. If stopping the watchdog is not
possible but the driver implements a stop function, it is responsible
to set the WDOG_RUNNING flag in its stop function.
Cc: Timo Kokkonen <timo.kokkonen@xxxxxxxxxx>
Cc: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
---
Documentation/watchdog/watchdog-kernel-api.txt | 19 ++++++++-----
drivers/watchdog/watchdog_core.c | 2 +-
drivers/watchdog/watchdog_dev.c | 39 ++++++++++++++++++++------
include/linux/watchdog.h | 7 +++++
4 files changed, 50 insertions(+), 17 deletions(-)
Another thing that I noticed just now after looking at a later patch in
this series: Conceptually that worker stuff better fits into
watchdog_core.c than watchdog_dev.c, doesn't it? But maybe this
separation doesn't make sense anyhow?
I actually started with that approach.
Problem is that the functionality added by the patch set is to a large degree
associated with code in watchdog_dev.c. I would have to export static functions
from watchdog_dev.c (such as _watchdog_ping), and I would have to export some
of the worker functions (such as watchdog_update_worker) if the code would be
in watchdog_core.c.
On the other side, when adding the code to watchdog_dev.c, I did not have to
export any functions. So adding the code there seemed to make more sense to me.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
