summaryrefslogtreecommitdiff
path: root/drivers/watchdog/watchdog_dev.c
AgeCommit message (Collapse)Author
2017-02-24watchdog: Introduce watchdog_stop_on_unregister helperGuenter Roeck
Many watchdog drivers explicitly stop the watchdog when unregistering it. While it is unclear if this is actually needed (the whatdog should not be running at that time if it can be stopped), introduce a helper to explicitly stop the watchdog in the watchdog core when unregistering it. This helps reducing driver code size while retaining functionality. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-10-08watchdog: pretimeout: add pretimeout_available_governors attributeVladimir Zapolskiy
The change adds an option to a user with CONFIG_WATCHDOG_SYSFS and CONFIG_WATCHDOG_PRETIMEOUT_GOV enabled to get information about all registered watchdog pretimeout governors by reading watchdog device attribute named "pretimeout_available_governors". Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-10-08watchdog: pretimeout: add option to select a pretimeout governor in runtimeVladimir Zapolskiy
The change converts watchdog device attribute "pretimeout_governor" from read-only to read-write type to allow users to select a desirable watchdog pretimeout governor in runtime, e.g. % echo -n panic > /sys/..../watchdog/watchdog0/pretimeout To get this working a list of registered pretimeout governors is created and a new helper function watchdog_pretimeout_governor_set() is exported to watchdog_dev.c. If a selected governor is gone, a watchdog device pretimeout notification is delegated to a default built-in pretimeout governor. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-10-08watchdog: add watchdog pretimeout governor frameworkVladimir Zapolskiy
The change adds a simple watchdog pretimeout framework infrastructure, its purpose is to allow users to select a desired handling of watchdog pretimeout events, which may be generated by some watchdog devices. A user selects a default watchdog pretimeout governor during compilation stage. Watchdogs with WDIOF_PRETIMEOUT capability now have one more device attribute in sysfs, pretimeout_governor attribute is intended to display the selected watchdog pretimeout governor. The framework has no impact at runtime on watchdog devices with no WDIOF_PRETIMEOUT capability set. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-09-24watchdog: add pretimeout support to the coreWolfram Sang
Since the watchdog framework centrializes the IOCTL interfaces of device drivers now, SETPRETIMEOUT and GETPRETIMEOUT need to be added in the common code. Signed-off-by: Robin Gong <b38343@freescale.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> [vzapolskiy: added conditional pretimeout sysfs attribute visibility] Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-07-25watchdog: core: Clear WDOG_HW_RUNNING before calling the stop functionGuenter Roeck
WDOG_HW_RUNNING indicates that the hardware watchdog is running while the watchdog device is closed. The flag may be set by the driver when it is instantiated to indicate that the watchdog is running, and that the watchdog core needs to send heartbeat requests to the driver until the watchdog device is opened. When the watchdog device is closed, the flag can be used by the driver's stop function to indicate to the watchdog core that it was unable to stop the watchdog, and that the watchdog core needs to send heartbeat requests. This only works if the flag is actually cleared when the watchdog is stopped. To avoid having to clear the flag in each driver's stop function, clear it in the watchdog core before calling the stop function. Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Fixes: ee142889e32f ("watchdog: Introduce WDOG_HW_RUNNING flag") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-07-25watchdog: core: Fix error handling of watchdog_dev_init()Wei Yongjun
Fix the error handling paths of watchdog_dev_init(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-07-19watchdog: Implement status function in watchdog coreGuenter Roeck
Up to now, the watchdog status function called a driver function, which was supposed to return the watchdog status. All but one driver using the watchdog core did not implement this function, and the driver implementing it did not implement it correctly (the function is supposed to return WDIOF_ flags). At the same time, at least some of the status information can be provided by the watchdog core. Provide the available status bits directly from the watchdog driver core. Call the driver status function if it exists to get the boot status, but always provide WDIOF_MAGICCLOSE and WDIOF_KEEPALIVEPING internally. This patch makes the 'status' sysfs attribute always available. This attribute is now displayed as hex number with 0x prepended to be easier to decode. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-07-17watchdog: change watchdog_need_worker logicRasmus Villemoes
If the driver indicates that the watchdog is running, the framework should feed it until userspace opens the device, regardless of whether the driver has set max_hw_heartbeat_ms. This patch only affects the case where wdd->max_hw_heartbeat_ms is zero, wdd->timeout is non-zero, the watchdog is not active and the hardware device is running (*): - If wdd->timeout is zero, watchdog_need_worker() returns false both before and after this patch, and watchdog_next_keepalive() is not called. - If watchdog_active(wdd), the return value from watchdog_need_worker is also the same as before (namely, hm && t > hm). Hence in that case, watchdog_next_keepalive() is only called if hm == max_hw_heartbeat_ms is non-zero, so the change to min_not_zero there is a no-op. - If the watchdog is not active and the device is not running, we return false from watchdog_need_worker just as before. That leaves the watchdog_hw_running(wdd) && !watchdog_active(wdd) && wdd->timeout case. Again, it's easy to see that if wdd->max_hw_heartbeat_ms is non-zero, we return true from watchdog_need_worker with and without this patch, and the logic in watchdog_next_keepalive is unchanged. Finally, if wdd->max_hw_heartbeat_ms is 0, we used to end up in the cancel_delayed_work branch, whereas with this patch we end up scheduling a ping timeout_ms/2 from now. (*) This should imply that no current kernel drivers are affected, since the only drivers which explicitly set WDOG_HW_RUNNING are imx2_wdt.c and dw_wdt.c, both of which also provide a non-zero value for max_hw_heartbeat_ms. The watchdog core also sets WDOG_HW_RUNNING, but only when the driver doesn't provide ->stop, in which case it must, according to Documentation/watchdog/watchdog-kernel-api.txt, set max_hw_heartbeat_ms. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-05-14watchdog: core: Fix circular locking dependencyGuenter Roeck
lockdep reports the following circular locking dependency. ====================================================== INFO: possible circular locking dependency detected ] 4.6.0-rc3-00191-gfabf418 #162 Not tainted ------------------------------------------------------- systemd/1 is trying to acquire lock: ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280 but task is already holding lock: (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&wd_data->lock){+.+...}: [<80662310>] mutex_lock_nested+0x64/0x4a8 [<804aca4c>] watchdog_ping_work+0x18/0x4c [<80143128>] process_one_work+0x1ac/0x500 [<801434b4>] worker_thread+0x38/0x554 [<80149510>] kthread+0xf4/0x108 [<80107c10>] ret_from_fork+0x14/0x24 -> #0 ((&(&wd_data->work)->work)){+.+...}: [<8017c4e8>] lock_acquire+0x70/0x90 [<8014169c>] flush_work+0x4c/0x280 [<801440f8>] __cancel_work_timer+0x9c/0x1e0 [<804acfcc>] watchdog_release+0x3c/0x190 [<8022c5e8>] __fput+0x80/0x1c8 [<80147b28>] task_work_run+0x94/0xc8 [<8010b998>] do_work_pending+0x8c/0xb4 [<80107ba8>] slow_work_pending+0xc/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&wd_data->lock); lock((&(&wd_data->work)->work)); lock(&wd_data->lock); lock((&(&wd_data->work)->work)); *** DEADLOCK *** 1 lock held by systemd/1: stack backtrace: CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 #162 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14) [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4) [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334) [<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8) [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec) [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90) [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280) [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0) [<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190) [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8) [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8) [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4) [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20) Turns out the call to cancel_delayed_work_sync() in watchdog_release() is not necessary and can be dropped. If the worker is no longer necessary, the subsequent call to watchdog_update_worker() will cancel it. If it is already running, it won't do anything, since the worker function checks if it needs to ping the watchdog or not. Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com> Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com> Fixes: 11d7aba9ceb7 ("watchdog: imx2: Convert to use infrastructure triggered keepalives") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Cc: stable <stable@vger.kernel.org>
2016-03-16watchdog: Ensure that wdd is not dereferenced if NULLGuenter Roeck
Smatch rightfully complains that wdd is dereferenced in the watchdog release function after being checked for NULL. Also make sure that it is not accessed outside mutex protection to avoid use-after-free problems. Fixes: e6c71e84e4c0 ("watchdog: Introduce WDOG_HW_RUNNING flag") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-03-16watchdog: Add support for minimum time between heartbeatsGuenter Roeck
Some watchdogs require a minimum time between heartbeats. Examples are the watchdogs in DA9062 and AT91SAM9x. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-03-16watchdog: Make stop function optionalGuenter Roeck
Not all hardware watchdogs can be stopped. The driver for such watchdogs would typically only set the WATCHDOG_HW_RUNNING flag in its stop function. Make the stop function optional and set WATCHDOG_HW_RUNNING in the watchdog core if it is not provided. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-03-16watchdog: Introduce WDOG_HW_RUNNING flagGuenter Roeck
The WDOG_HW_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_HW_RUNNING flag in its stop function. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-03-16watchdog: Introduce hardware maximum heartbeat in watchdog coreGuenter Roeck
Introduce an optional hardware maximum heartbeat in the watchdog core. The hardware maximum heartbeat can be lower than the maximum timeout. Drivers can set the maximum hardware heartbeat value in the watchdog data structure. If the configured timeout exceeds the maximum hardware heartbeat, the watchdog core enables a timer function to assist sending keepalive requests to the watchdog driver. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-03-16watchdog: Make set_timeout function optionalGuenter Roeck
For some watchdogs, the watchdog driver handles timeout changes without explicitly setting any registers. In this situation, the watchdog driver might only set the 'timeout' variable but do nothing else. This can as well be handled by the infrastructure, so make the set_timeout callback optional. If WDIOF_SETTIMEOUT is configured but the .set_timeout callback is not available, update the timeout variable in the infrastructure code. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-01-11watchdog: Drop pointer to watchdog device from struct watchdog_deviceGuenter Roeck
The lifetime of the watchdog device pointer is different from the lifetime of its character device. Remove it entirely to avoid race conditions. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2016-01-11watchdog: Add support for creating driver specific sysfs attributesGuenter Roeck
The Zodiac watchdog driver attaches additional sysfs attributes to the watchdog device. This has a number of problems: The watchdog device lifetime differs from the driver lifetime, and the device structure should therefore not be accessed from drivers. Also, creating sysfs attributes after driver registration results in a potential race condition if user space expects the attributes to exist but they don't exist yet. Add support for creating driver specific sysfs attributes to the watchdog core to solve the problems. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-12-29watchdog: Separate and maintain variables based on variable lifetimeGuenter Roeck
All variables required by the watchdog core to manage a watchdog are currently stored in struct watchdog_device. The lifetime of those variables is determined by the watchdog driver. However, the lifetime of variables used by the watchdog core differs from the lifetime of struct watchdog_device. To remedy this situation, watchdog drivers can implement ref and unref callbacks, to be used by the watchdog core to lock struct watchdog_device in memory. While this solves the immediate problem, it depends on watchdog drivers to actually implement the ref/unref callbacks. This is error prone, often not implemented in the first place, or not implemented correctly. To solve the problem without requiring driver support, split the variables in struct watchdog_device into two data structures - one for variables associated with the watchdog driver, one for variables associated with the watchdog core. With this approach, the watchdog core can keep track of its variable lifetime and no longer depends on ref/unref callbacks in the driver. As a side effect, some of the variables originally in struct watchdog_driver are now private to the watchdog core and no longer visible in watchdog drivers. As a side effect of the changes made, an ioctl will now always fail with -ENODEV after a watchdog device was unregistered with the character device still open. Previously, it would only fail with -ENODEV in some situations. Also, ioctl operations are now atomic from driver perspective. With this change, it is now guaranteed that the driver will not unregister a watchdog between a timeout change and the subsequent ping. The 'ref' and 'unref' callbacks in struct watchdog_driver are no longer used and marked as deprecated. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-12-29watchdog: Create watchdog device in watchdog_dev.cGuenter Roeck
The watchdog character device is currently created in watchdog_dev.c, and the watchdog device in watchdog_core.c. This results in cross-dependencies, since device creation needs to know the watchdog character device number as well as the watchdog class, both of which reside in watchdog_dev.c. Create the watchdog device in watchdog_dev.c to simplify the code. Inspired by earlier patch set from Damien Riegel. Cc: Damien Riegel <damien.riegel@savoirfairelinux.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-12-27watchdog: Read device status through sysfs attributesPratyush Anand
This patch adds following attributes to watchdog device's sysfs interface to read its different status. * state - reads whether device is active or not * identity - reads Watchdog device's identity string. * timeout - reads current timeout. * timeleft - reads timeleft before watchdog generates a reset * bootstatus - reads status of the watchdog device at boot * status - reads watchdog device's internal status bits * nowayout - reads whether nowayout feature was set or not Testing with iTCO_wdt: # cd /sys/class/watchdog/watchdog1/ # ls bootstatus dev device identity nowayout power state subsystem timeleft timeout uevent # cat identity iTCO_wdt # cat timeout 30 # cat state inactive # echo > /dev/watchdog1 # cat timeleft 26 # cat state active # cat bootstatus 0 # cat nowayout 0 Signed-off-by: Pratyush Anand <panand@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-12-27watchdog: Use static struct class watchdog_class in stead of pointerPratyush Anand
We need few sysfs attributes to know different status of a watchdog device. To do that, we need to associate .dev_groups with watchdog_class. So convert it from pointer to static. Putting this static struct in watchdog_dev.c, so that static device attributes defined in that file can be attached to it. Signed-off-by: Pratyush Anand <panand@redhat.com> Suggested-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-11-03watchdog: core: propagate ping error code to the user spaceAlexander Usyskin
Watchdog ping return errors are ignored by watchdog core, Whatchdog daemon should be informed about possible hardware error or underlaying device driver get unregistered. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2015-11-03watchdog: watchdog_dev: Use single variable name for struct watchdog_deviceGuenter Roeck
The current code uses 'wdd', wddev', and 'watchdog' as variable names for struct watchdog_device. This is confusing and makes it difficult to enhance the code. Replace it all with 'wdd'. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: Timo Kokkonen <timo.kokkonen@offcode.fi> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2013-07-11watchdog: core: don't try to stop device if not runningHector Palacios
A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS ioctl and flag WDIOS_DISABLECARD. If the device is closed after this operation, watchdog_release() is called and status bits checked for stopping it. Besides, if the device has not been unregistered a critical message "watchdog did not stop!" is printed, although the ioctl may have successfully stopped it already. Without the patch a user application sample code like this will successfully stop the watchdog, but the kernel will output the message "watchdog did not stop!": wd_fd = open("/dev/watchdog", O_RDWR); flags = WDIOS_DISABLECARD; ioctl(wd_fd, WDIOC_SETOPTIONS, &flags); close(wd_fd); Signed-off-by: Hector Palacios <hector.palacios@digi.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2013-05-09watchdog: Fix race condition in registration codeGuenter Roeck
A race condition exists when registering the first watchdog device. Sequence of events: - watchdog_register_device calls watchdog_dev_register - watchdog_dev_register creates the watchdog misc device by calling misc_register. At that time, the matching character device (/dev/watchdog0) does not yet exist, and old_wdd is not set either. - Userspace gets an event and opens /dev/watchdog - watchdog_open is called and sets wdd = old_wdd, which is still NULL, and tries to dereference it. This causes the kernel to panic. Seen with systemd trying to open /dev/watchdog immediately after it was created. Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2013-03-01watchdog: core: dt: add support for the timeout-sec dt propertyFabio Porcedda
Add support for watchdog drivers to initialize/set the timeout field of the watchdog_device structure. The timeout field is initialised either with the module timeout parameter value (if valid) or with the timeout-sec dt property (if valid). If both are invalid the initial value is unchanged. Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-06-28watchdog: core: fix WDIOC_GETSTATUS return valueWim Van Sebroeck
In commit 7a87982420e5e126bfefeb42232d1fd92052794e we added a wrapper for the WDIOC_GETSTATUS ioctl call. The code results however in a different behaviour: it returns an error if the driver doesn't support the status operation. This is not according to the API that says that when we don't support the status operation, that we just should return a 0 value. Only when the device isn't there anymore, we should return an error. Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: Add support for dynamically allocated watchdog_device structsHans de Goede
If a driver's watchdog_device struct is part of a dynamically allocated struct (which it often will be), merely locking the module is not enough, even with a drivers module locked, the driver can be unbound from the device, examples: 1) The root user can unbind it through sysfd 2) The i2c bus master driver being unloaded for an i2c watchdog I will gladly admit that these are corner cases, but we still need to handle them correctly. The fix for this consists of 2 parts: 1) Add ref / unref operations, so that the driver can refcount the struct holding the watchdog_device struct and delay freeing it until any open filehandles referring to it are closed 2) Most driver operations will do IO on the device and the driver should not do any IO on the device after it has been unbound. Rather then letting each driver deal with this internally, it is better to ensure at the watchdog core level that no operations (other then unref) will get called after the driver has called watchdog_unregister_device(). This actually is the bulk of this patch. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: Add Locking supportHans de Goede
This patch fixes some potential multithreading issues, despite only allowing one process to open the /dev/watchdog device, we can still get called multiple times at the same time, since a program could be using thread, or could share the fd after a fork. This causes 2 potential problems: 1) watchdog_start / open do an unlocked test_n_set / test_n_clear, if these 2 race, the watchdog could be stopped while the active bit indicates it is running or visa versa. 2) Most watchdog_dev drivers probably assume that only one watchdog-op will get called at a time, this is not necessary true atm. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: watchdog_dev: Rewrite wrapper codeHans de Goede
Rewrite and extend the wrapper code so that we can easily introduce locking (this to be able to prevent potential multithreading issues). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: use dev_ functionsAlan Cox
While they are registered all our watchdogs now have a valid device object so we can in turn use that to report problems nicely. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: create all the proper device filesAlan Cox
Create the watchdog class and it's associated devices. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: Add multiple device supportAlan Cox
We keep the old /dev/watchdog interface file for the first watchdog via miscdev. This is basically a cut and paste of the relevant interface code from the rtc driver layer tweaked for watchdog. Revised to fix problems noted by Hans de Goede Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: correct the name of the watchdog_core inlude fileWim Van Sebroeck
The watchdog_core include file should have been named watchdog_core.h and not watchdog_dev.h . Correct this. Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: Add watchdog_active() routineViresh Kumar
Some watchdog may need to check if watchdog is ACTIVE or not, for example in their suspend/resume hooks. This patch adds this routine and changes the core drivers to use it. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-05-30watchdog: watchdog_dev: include private header to pickup global symbol ↵H Hartley Sweeten
prototypes Include the private watchdog_dev.h header to pickup the prototypes for the watchdog_dev_register/unregister functions. This quiets the following sparse warnings: warning: symbol 'watchdog_dev_register' was not declared. Should it be static? warning: symbol 'watchdog_dev_unregister' was not declared. Should it be static? Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-03-27watchdog: Add support for WDIOC_GETTIMELEFT IOCTL in watchdog coreViresh Kumar
This patch adds support for WDIOC_GETTIMELEFT IOCTL in watchdog core. So, there is another function pointer added to struct watchdog_ops, which can be passed by drivers to support this IOCTL. Related documentation is updated too. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-03-27watchdog: watchdog_dev: Let the driver update the timeout field on ↵Hans de Goede
set_timeout success When a set_timeout operation succeeds this does not necessarily mean that the exact timeout requested has been achieved, because the watchdog does not necessarily have a 1 second resolution. So rather then have the core set the timeout member of the watchdog_device struct to the exact requested value, instead the driver should set it to the actually achieved timeout value. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2012-03-27watchdog: Use pr_<fmt> and pr_<level>Joe Perches
Use the current logging styles. Make sure all output has a prefix. Add missing newlines. Remove now unnecessary PFX, NAME, and miscellaneous other #defines. Coalesce formats. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2011-09-20watchdog: WatchDog Timer Driver Core - use passed watchdog_deviceH Hartley Sweeten
Use the passed watchdog_device instead of the static global variable when testing and setting the status in watchdog_ping, watchdog_start, and watchdog_stop. Note that the callers of these functions are actually passing the static global variable. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2011-07-28watchdog: WatchDog Timer Driver Core - Add minimum and max timeoutWim Van Sebroeck
Add min_timeout (minimum timeout) and max_timeout values so that the framework can check if the new timeout value is between the minimum and maximum timeout values. If both values are 0, then the framework will leave the check for the watchdog device driver itself. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add ioctl callWim Van Sebroeck
Add support for extra ioctl calls by adding a ioctl watchdog operation. This operation will be called before we do our own handling of ioctl commands. This way we can override the internal ioctl command handling and we can also add extra ioctl commands. The ioctl watchdog operation should return the appropriate error codes or -ENOIOCTLCMD if the ioctl command should be handled through the internal ioctl handling of the framework. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add nowayout featureWim Van Sebroeck
Add support for the nowayout feature to the WatchDog Timer Driver Core framework. This feature prevents the watchdog timer from being stopped. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add Magic Close featureWim Van Sebroeck
Add support for the Magic Close feature to the WatchDog Timer Driver Core framework. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add WDIOC_SETTIMEOUT and ↵Wim Van Sebroeck
WDIOC_GETTIMEOUT ioctl This part add's the WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT ioctl functionality to the WatchDog Timer Driver Core framework. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add WDIOC_SETOPTIONS ioctlWim Van Sebroeck
This part add's the WDIOC_SETOPTIONS ioctl functionality to the WatchDog Timer Driver Core framework. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add WDIOC_KEEPALIVE ioctlWim Van Sebroeck
This part add's the WDIOC_KEEPALIVE ioctl functionality to the WatchDog Timer Driver Core framework. Please note that the WDIOF_KEEPALIVEPING bit has to be set in the watchdog_info options field. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add basic ioctl functionalityWim Van Sebroeck
This part add's the basic ioctl functionality to the WatchDog Timer Driver Core framework. The supported ioctl call's are: WDIOC_GETSUPPORT WDIOC_GETSTATUS WDIOC_GETBOOTSTATUS Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
2011-07-28watchdog: WatchDog Timer Driver Core - Add basic frameworkWim Van Sebroeck
The WatchDog Timer Driver Core is a framework that contains the common code for all watchdog-driver's. It also introduces a watchdog device structure and the operations that go with it. This is the introduction of this framework. This part supports the minimal watchdog userspace API (or with other words: the functionality to use /dev/watchdog's open, release and write functionality as defined in the simplest watchdog API). Extra functionality will follow in the next set of patches. Signed-off-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <w.sang@pengutronix.de>