linux-stable/drivers/watchdog/watchdog_core.h

82 lines
2.7 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0+ */
/*
* watchdog_core.h
*
* (c) Copyright 2008-2011 Alan Cox <alan@lxorguk.ukuu.org.uk>,
* All Rights Reserved.
*
* (c) Copyright 2008-2011 Wim Van Sebroeck <wim@iguana.be>.
*
watchdog: Add hrtimer-based pretimeout feature This adds the option to use a hrtimer to generate a watchdog pretimeout event for hardware watchdogs that do not natively support watchdog pretimeouts. With this enabled, all watchdogs will appear to have pretimeout support in userspace. If no pretimeout value is set, there will be no change in the watchdog's behavior. If a pretimeout value is set for a specific watchdog that does not have built-in pretimeout support, a timer will be started that should fire at the specified time before the watchdog timeout would occur. When the watchdog is successfully pinged, the timer will be restarted. If the timer is allowed to fire it will generate a pretimeout event. However because a software timer is used, it may not be able to fire in every circumstance. If the watchdog does support a pretimeout natively, that functionality will be used instead of the hrtimer. The general design of this feaure was inspired by the software watchdog, specifically its own pretimeout implementation. However the software watchdog and this feature are completely independent. They can be used together; with or without CONFIG_SOFT_WATCHDOG_PRETIMEOUT enabled. The main advantage of using the hrtimer pretimeout with a hardware watchdog, compared to running the software watchdog with a hardware watchdog, is that if the hardware watchdog driver is unable to ping the watchdog (e.g. due to a bus or communication error), then the hrtimer pretimeout would still fire whereas the software watchdog would not. Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1612383090-27110-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
2021-02-03 20:11:30 +00:00
* (c) Copyright 2021 Hewlett Packard Enterprise Development LP.
*
* This source code is part of the generic code that can be used
* by all the watchdog timer drivers.
*
* Based on source code of the following authors:
* Matt Domsch <Matt_Domsch@dell.com>,
* Rob Radez <rob@osinvestor.com>,
* Rusty Lynch <rusty@linux.co.intel.com>
* Satyam Sharma <satyam@infradead.org>
* Randy Dunlap <randy.dunlap@oracle.com>
*
* Neither Alan Cox, CymruNet Ltd., Wim Van Sebroeck nor Iguana vzw.
* admit liability nor provide warranty for any of this software.
* This material is provided "AS-IS" and at no charge.
*/
watchdog: Add hrtimer-based pretimeout feature This adds the option to use a hrtimer to generate a watchdog pretimeout event for hardware watchdogs that do not natively support watchdog pretimeouts. With this enabled, all watchdogs will appear to have pretimeout support in userspace. If no pretimeout value is set, there will be no change in the watchdog's behavior. If a pretimeout value is set for a specific watchdog that does not have built-in pretimeout support, a timer will be started that should fire at the specified time before the watchdog timeout would occur. When the watchdog is successfully pinged, the timer will be restarted. If the timer is allowed to fire it will generate a pretimeout event. However because a software timer is used, it may not be able to fire in every circumstance. If the watchdog does support a pretimeout natively, that functionality will be used instead of the hrtimer. The general design of this feaure was inspired by the software watchdog, specifically its own pretimeout implementation. However the software watchdog and this feature are completely independent. They can be used together; with or without CONFIG_SOFT_WATCHDOG_PRETIMEOUT enabled. The main advantage of using the hrtimer pretimeout with a hardware watchdog, compared to running the software watchdog with a hardware watchdog, is that if the hardware watchdog driver is unable to ping the watchdog (e.g. due to a bus or communication error), then the hrtimer pretimeout would still fire whereas the software watchdog would not. Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1612383090-27110-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
2021-02-03 20:11:30 +00:00
#include <linux/hrtimer.h>
#include <linux/kthread.h>
#define MAX_DOGS 32 /* Maximum number of watchdog devices */
watchdog: Add hrtimer-based pretimeout feature This adds the option to use a hrtimer to generate a watchdog pretimeout event for hardware watchdogs that do not natively support watchdog pretimeouts. With this enabled, all watchdogs will appear to have pretimeout support in userspace. If no pretimeout value is set, there will be no change in the watchdog's behavior. If a pretimeout value is set for a specific watchdog that does not have built-in pretimeout support, a timer will be started that should fire at the specified time before the watchdog timeout would occur. When the watchdog is successfully pinged, the timer will be restarted. If the timer is allowed to fire it will generate a pretimeout event. However because a software timer is used, it may not be able to fire in every circumstance. If the watchdog does support a pretimeout natively, that functionality will be used instead of the hrtimer. The general design of this feaure was inspired by the software watchdog, specifically its own pretimeout implementation. However the software watchdog and this feature are completely independent. They can be used together; with or without CONFIG_SOFT_WATCHDOG_PRETIMEOUT enabled. The main advantage of using the hrtimer pretimeout with a hardware watchdog, compared to running the software watchdog with a hardware watchdog, is that if the hardware watchdog driver is unable to ping the watchdog (e.g. due to a bus or communication error), then the hrtimer pretimeout would still fire whereas the software watchdog would not. Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1612383090-27110-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
2021-02-03 20:11:30 +00:00
/*
* struct watchdog_core_data - watchdog core internal data
* @dev: The watchdog's internal device
* @cdev: The watchdog's Character device.
* @wdd: Pointer to watchdog device.
* @lock: Lock for watchdog core.
* @status: Watchdog core internal status bits.
*/
struct watchdog_core_data {
struct device dev;
struct cdev cdev;
struct watchdog_device *wdd;
struct mutex lock;
ktime_t last_keepalive;
ktime_t last_hw_keepalive;
ktime_t open_deadline;
struct hrtimer timer;
struct kthread_work work;
#if IS_ENABLED(CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT)
struct hrtimer pretimeout_timer;
#endif
unsigned long status; /* Internal status bits */
#define _WDOG_DEV_OPEN 0 /* Opened ? */
#define _WDOG_ALLOW_RELEASE 1 /* Did we receive the magic char ? */
#define _WDOG_KEEPALIVE 2 /* Did we receive a keepalive ? */
};
/*
* Functions/procedures to be called by the core
*/
extern int watchdog_dev_register(struct watchdog_device *);
extern void watchdog_dev_unregister(struct watchdog_device *);
extern int __init watchdog_dev_init(void);
extern void __exit watchdog_dev_exit(void);
watchdog: Add hrtimer-based pretimeout feature This adds the option to use a hrtimer to generate a watchdog pretimeout event for hardware watchdogs that do not natively support watchdog pretimeouts. With this enabled, all watchdogs will appear to have pretimeout support in userspace. If no pretimeout value is set, there will be no change in the watchdog's behavior. If a pretimeout value is set for a specific watchdog that does not have built-in pretimeout support, a timer will be started that should fire at the specified time before the watchdog timeout would occur. When the watchdog is successfully pinged, the timer will be restarted. If the timer is allowed to fire it will generate a pretimeout event. However because a software timer is used, it may not be able to fire in every circumstance. If the watchdog does support a pretimeout natively, that functionality will be used instead of the hrtimer. The general design of this feaure was inspired by the software watchdog, specifically its own pretimeout implementation. However the software watchdog and this feature are completely independent. They can be used together; with or without CONFIG_SOFT_WATCHDOG_PRETIMEOUT enabled. The main advantage of using the hrtimer pretimeout with a hardware watchdog, compared to running the software watchdog with a hardware watchdog, is that if the hardware watchdog driver is unable to ping the watchdog (e.g. due to a bus or communication error), then the hrtimer pretimeout would still fire whereas the software watchdog would not. Signed-off-by: Curtis Klein <curtis.klein@hpe.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1612383090-27110-1-git-send-email-curtis.klein@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
2021-02-03 20:11:30 +00:00
static inline bool watchdog_have_pretimeout(struct watchdog_device *wdd)
{
return wdd->info->options & WDIOF_PRETIMEOUT ||
IS_ENABLED(CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT);
}
#if IS_ENABLED(CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT)
void watchdog_hrtimer_pretimeout_init(struct watchdog_device *wdd);
void watchdog_hrtimer_pretimeout_start(struct watchdog_device *wdd);
void watchdog_hrtimer_pretimeout_stop(struct watchdog_device *wdd);
#else
static inline void watchdog_hrtimer_pretimeout_init(struct watchdog_device *wdd) {}
static inline void watchdog_hrtimer_pretimeout_start(struct watchdog_device *wdd) {}
static inline void watchdog_hrtimer_pretimeout_stop(struct watchdog_device *wdd) {}
#endif