watchdog: add watchdog pretimeout governor framework

The change adds a simple watchdog pretimeout framework infrastructure,
its purpose is to allow users to select a desired handling of watchdog
pre

watchdog: add watchdog pretimeout governor framework

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>

show more ...

watchdog: add pretimeout support to the core

Since the watchdog framework centrializes the IOCTL interfaces of device
drivers now, SETPRETIMEOUT and GETPRETIMEOUT need to be added in the
common code

watchdog: add pretimeout support to the core

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>

show more ...

watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function

WDOG_HW_RUNNING indicates that the hardware watchdog is running while the
watchdog device is closed. The flag may be set by the

watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function

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>

show more ...

watchdog: core: Fix error handling of watchdog_dev_init()

Fix the error handling paths of watchdog_dev_init().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Guenter Roeck

watchdog: core: Fix error handling of watchdog_dev_init()

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>

show more ...

watchdog: Implement status function in watchdog core

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: Implement status function in watchdog core

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>

show more ...

watchdog: change watchdog_need_worker logic

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

watchdog: change watchdog_need_worker logic

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>

show more ...

watchdog: core: Fix circular locking dependency

lockdep reports the following circular locking dependency.

======================================================
INFO: possible circular locking dep

watchdog: core: Fix circular locking dependency

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>

show more ...

watchdog: Ensure that wdd is not dereferenced if NULL

Smatch rightfully complains that wdd is dereferenced in the watchdog
release function after being checked for NULL. Also make sure that it
is no

watchdog: Ensure that wdd is not dereferenced if NULL

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>

show more ...

watchdog: Add support for minimum time between heartbeats

Some watchdogs require a minimum time between heartbeats.
Examples are the watchdogs in DA9062 and AT91SAM9x.

Signed-off-by: Guenter Roeck

watchdog: Add support for minimum time between heartbeats

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>

show more ...

watchdog: Make stop function optional

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 st

watchdog: Make stop function optional

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>

show more ...

watchdog: Introduce WDOG_HW_RUNNING flag

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

watchdog: Introduce WDOG_HW_RUNNING flag

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>

show more ...

watchdog: Introduce hardware maximum heartbeat in watchdog core

Introduce an optional hardware maximum heartbeat in the watchdog core.
The hardware maximum heartbeat can be lower than the maximum ti

watchdog: Introduce hardware maximum heartbeat in watchdog core

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>

show more ...

watchdog: Make set_timeout function optional

For some watchdogs, the watchdog driver handles timeout changes without
explicitly setting any registers. In this situation, the watchdog driver
might on

watchdog: Make set_timeout function optional

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>

show more ...

watchdog: Drop pointer to watchdog device from struct watchdog_device

The lifetime of the watchdog device pointer is different from the lifetime
of its character device. Remove it entirely to avoid

watchdog: Drop pointer to watchdog device from struct watchdog_device

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>

show more ...

watchdog: Add support for creating driver specific sysfs attributes

The Zodiac watchdog driver attaches additional sysfs attributes to the
watchdog device. This has a number of problems: The watchdo

watchdog: Add support for creating driver specific sysfs attributes

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>

show more ...

watchdog: Separate and maintain variables based on variable lifetime

All variables required by the watchdog core to manage a watchdog are
currently stored in struct watchdog_device. The lifetime of

watchdog: Separate and maintain variables based on variable lifetime

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>

show more ...

watchdog: Create watchdog device in watchdog_dev.c

The watchdog character device is currently created in watchdog_dev.c,
and the watchdog device in watchdog_core.c. This results in
cross-dependencie

watchdog: Create watchdog device in watchdog_dev.c

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>

show more ...

watchdog: Read device status through sysfs attributes

This patch adds following attributes to watchdog device's sysfs interface
to read its different status.

* state - reads whether device is activ

watchdog: Read device status through sysfs attributes

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>

show more ...

watchdog: Use static struct class watchdog_class in stead of pointer

We need few sysfs attributes to know different status of a watchdog device.
To do that, we need to associate .dev_groups with wat

watchdog: Use static struct class watchdog_class in stead of pointer

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>

show more ...

watchdog: core: propagate ping error code to the user space

Watchdog ping return errors are ignored by watchdog core,
Whatchdog daemon should be informed about possible hardware error or
underlaying

watchdog: core: propagate ping error code to the user space

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>

show more ...

watchdog: watchdog_dev: Use single variable name for struct watchdog_device

The current code uses 'wdd', wddev', and 'watchdog' as variable names
for struct watchdog_device. This is confusing and ma

watchdog: watchdog_dev: Use single variable name for struct watchdog_device

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>

show more ...

watchdog: core: don't try to stop device if not running

A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS
ioctl and flag WDIOS_DISABLECARD. If the device is closed after this
op

watchdog: core: don't try to stop device if not running

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>

show more ...

watchdog: Fix race condition in registration code

A race condition exists when registering the first watchdog device.
Sequence of events:

- watchdog_register_device calls watchdog_dev_register
- wa

watchdog: Fix race condition in registration code

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>

show more ...

watchdog: core: dt: add support for the timeout-sec dt property

Add support for watchdog drivers to initialize/set the timeout field
of the watchdog_device structure. The timeout field is initialise

watchdog: core: dt: add support for the timeout-sec dt property

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>

show more ...

watchdog: core: fix WDIOC_GETSTATUS return value

In commit 7a87982420e5e126bfefeb42232d1fd92052794e we added
a wrapper for the WDIOC_GETSTATUS ioctl call. The code results
however in a different beh

watchdog: core: fix WDIOC_GETSTATUS return value

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>

show more ...