linux-stable.git/drivers/watchdog, branch v4.6.2 Linux kernel stable tree watchdog: sp5100_tco: properly check for new register layouts 2016-06-01T19:18:03+00:00 Lucas Stach dev@lynxeye.de 2016-05-03T17:15:58+00:00 9411afb65b049c35d5faaaff677eb27bf6c85f42 commit 46856fabe40cc80f92134683cdec7dc0fc8f4000 upstream. Commits 190aa4304de6 (Add AMD Mullins platform support) and cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the driver on a lot more devices, but the following commit missed a single location in the code when checking if the SB800 register offsets should be used. This leads to the wrong register being written which in turn causes ACPI to go haywire. Fix this by introducing a helper function to check for the new register layout and use this consistently. https://bugzilla.kernel.org/show_bug.cgi?id=114201 https://bugzilla.redhat.com/show_bug.cgi?id=1329910 Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800 and later chipsets) Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 46856fabe40cc80f92134683cdec7dc0fc8f4000 upstream.

Commits 190aa4304de6 (Add AMD Mullins platform support) and
cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the
driver on a lot more devices, but the following commit missed
a single location in the code when checking if the SB800 register
offsets should be used. This leads to the wrong register being
written which in turn causes ACPI to go haywire.

Fix this by introducing a helper function to check for the new
register layout and use this consistently.

https://bugzilla.kernel.org/show_bug.cgi?id=114201
https://bugzilla.redhat.com/show_bug.cgi?id=1329910
Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800
and later chipsets)
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
watchdog: core: Fix circular locking dependency 2016-06-01T19:18:03+00:00 Guenter Roeck linux@roeck-us.net 2016-04-21T14:38:14+00:00 21abae567dffb8c6ddff24261acd19f554abfa28 commit e1f30282a1d3d0c75d5a08e47c6ac1563065be52 upstream. 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)); 
commit e1f30282a1d3d0c75d5a08e47c6ac1563065be52 upstream.

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));
hpwdt: use nmi_panic() when kernel panics in NMI handler 2016-03-22T22:36:02+00:00 Hidehiro Kawai hidehiro.kawai.ez@hitachi.com 2016-03-22T21:27:24+00:00 abc514c58059ca6f02df41798e828ffd864f1d21 Commit 1717f2096b54 ("panic, x86: Fix re-entrance problem due to panic on NMI") introduced nmi_panic() which prevents concurrent and recursive execution of panic(). It also saves registers for the crash dump on x86 by later commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even if looping in NMI context"). hpwdt driver can call panic() from NMI handler, so replace it with nmi_panic(). Also, do some cleanups. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: Thomas Mingarelli <thomas.mingarelli@hpe.com> Cc: Wim Van Sebroeck <wim@iguana.be> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Commit 1717f2096b54 ("panic, x86: Fix re-entrance problem due to panic
on NMI") introduced nmi_panic() which prevents concurrent and recursive
execution of panic().  It also saves registers for the crash dump on x86
by later commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers
even if looping in NMI context").

hpwdt driver can call panic() from NMI handler, so replace it with
nmi_panic().  Also, do some cleanups.

Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Cc: Thomas Mingarelli <thomas.mingarelli@hpe.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2016-03-21T01:23:21+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-03-21T01:23:21+00:00 26660a4046b171a752e72a1dd32153230234fe3a Pull 'objtool' stack frame validation from Ingo Molnar: "This tree adds a new kernel build-time object file validation feature (ONFIG_STACK_VALIDATION=y): kernel stack frame correctness validation. It was written by and is maintained by Josh Poimboeuf. The motivation: there's a category of hard to find kernel bugs, most of them in assembly code (but also occasionally in C code), that degrades the quality of kernel stack dumps/backtraces. These bugs are hard to detect at the source code level. Such bugs result in incorrect/incomplete backtraces most of time - but can also in some rare cases result in crashes or other undefined behavior. The build time correctness checking is done via the new 'objtool' user-space utility that was written for this purpose and which is hosted in the kernel repository in tools/objtool/. The tool's (very simple) UI and source code design is shaped after Git and perf and shares quite a bit of infrastructure with tools/perf (which tooling infrastructure sharing effort got merged via perf and is already upstream). Objtool follows the well-known kernel coding style. Objtool does not try to check .c or .S files, it instead analyzes the resulting .o generated machine code from first principles: it decodes the instruction stream and interprets it. (Right now objtool supports the x86-64 architecture.) From tools/objtool/Documentation/stack-validation.txt: "The kernel CONFIG_STACK_VALIDATION option enables a host tool named objtool which runs at compile time. It has a "check" subcommand which analyzes every .o file and ensures the validity of its stack metadata. It enforces a set of rules on asm code and C inline assembly code so that stack traces can be reliable. Currently it only checks frame pointer usage, but there are plans to add CFI validation for C files and CFI generation for asm files. For each function, it recursively follows all possible code paths and validates the correct frame pointer state at each instruction. It also follows code paths involving special sections, like .altinstructions, __jump_table, and __ex_table, which can add alternative execution paths to a given instruction (or set of instructions). Similarly, it knows how to follow switch statements, for which gcc sometimes uses jump tables." When this new kernel option is enabled (it's disabled by default), the tool, if it finds any suspicious assembly code pattern, outputs warnings in compiler warning format: warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch warning: objtool: cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup warning: objtool:__schedule()+0x3c0: duplicate frame pointer save warning: objtool:__schedule()+0x3fd: sibling call from callable instruction with changed frame pointer ... so that scripts that pick up compiler warnings will notice them. All known warnings triggered by the tool are fixed by the tree, most of the commits in fact prepare the kernel to be warning-free. Most of them are bugfixes or cleanups that stand on their own, but there are also some annotations of 'special' stack frames for justified cases such entries to JIT-ed code (BPF) or really special boot time code. There are two other long-term motivations behind this tool as well: - To improve the quality and reliability of kernel stack frames, so that they can be used for optimized live patching. - To create independent infrastructure to check the correctness of CFI stack frames at build time. CFI debuginfo is notoriously unreliable and we cannot use it in the kernel as-is without extra checking done both on the kernel side and on the build side. The quality of kernel stack frames matters to debuggability as well, so IMO we can merge this without having to consider the live patching or CFI debuginfo angle" * 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits) objtool: Only print one warning per function objtool: Add several performance improvements tools: Copy hashtable.h into tools directory objtool: Fix false positive warnings for functions with multiple switch statements objtool: Rename some variables and functions objtool: Remove superflous INIT_LIST_HEAD objtool: Add helper macros for traversing instructions objtool: Fix false positive warnings related to sibling calls objtool: Compile with debugging symbols objtool: Detect infinite recursion objtool: Prevent infinite recursion in noreturn detection objtool: Detect and warn if libelf is missing and don't break the build tools: Support relative directory path for 'O=' objtool: Support CROSS_COMPILE x86/asm/decoder: Use explicitly signed chars objtool: Enable stack metadata validation on 64-bit x86 objtool: Add CONFIG_STACK_VALIDATION option objtool: Add tool to perform compile-time stack metadata validation x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard sched: Always inline context_switch() ... 
Pull 'objtool' stack frame validation from Ingo Molnar:
 "This tree adds a new kernel build-time object file validation feature
  (ONFIG_STACK_VALIDATION=y): kernel stack frame correctness validation.
  It was written by and is maintained by Josh Poimboeuf.

  The motivation: there's a category of hard to find kernel bugs, most
  of them in assembly code (but also occasionally in C code), that
  degrades the quality of kernel stack dumps/backtraces.  These bugs are
  hard to detect at the source code level.  Such bugs result in
  incorrect/incomplete backtraces most of time - but can also in some
  rare cases result in crashes or other undefined behavior.

  The build time correctness checking is done via the new 'objtool'
  user-space utility that was written for this purpose and which is
  hosted in the kernel repository in tools/objtool/.  The tool's (very
  simple) UI and source code design is shaped after Git and perf and
  shares quite a bit of infrastructure with tools/perf (which tooling
  infrastructure sharing effort got merged via perf and is already
  upstream).  Objtool follows the well-known kernel coding style.

  Objtool does not try to check .c or .S files, it instead analyzes the
  resulting .o generated machine code from first principles: it decodes
  the instruction stream and interprets it.  (Right now objtool supports
  the x86-64 architecture.)

  From tools/objtool/Documentation/stack-validation.txt:

   "The kernel CONFIG_STACK_VALIDATION option enables a host tool named
    objtool which runs at compile time.  It has a "check" subcommand
    which analyzes every .o file and ensures the validity of its stack
    metadata.  It enforces a set of rules on asm code and C inline
    assembly code so that stack traces can be reliable.

    Currently it only checks frame pointer usage, but there are plans to
    add CFI validation for C files and CFI generation for asm files.

    For each function, it recursively follows all possible code paths
    and validates the correct frame pointer state at each instruction.

    It also follows code paths involving special sections, like
    .altinstructions, __jump_table, and __ex_table, which can add
    alternative execution paths to a given instruction (or set of
    instructions).  Similarly, it knows how to follow switch statements,
    for which gcc sometimes uses jump tables."

  When this new kernel option is enabled (it's disabled by default), the
  tool, if it finds any suspicious assembly code pattern, outputs
  warnings in compiler warning format:

    warning: objtool: rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
    warning: objtool: cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
    warning: objtool:__schedule()+0x3c0: duplicate frame pointer save
    warning: objtool:__schedule()+0x3fd: sibling call from callable instruction with changed frame pointer

  ... so that scripts that pick up compiler warnings will notice them.
  All known warnings triggered by the tool are fixed by the tree, most
  of the commits in fact prepare the kernel to be warning-free.  Most of
  them are bugfixes or cleanups that stand on their own, but there are
  also some annotations of 'special' stack frames for justified cases
  such entries to JIT-ed code (BPF) or really special boot time code.

  There are two other long-term motivations behind this tool as well:

   - To improve the quality and reliability of kernel stack frames, so
     that they can be used for optimized live patching.

   - To create independent infrastructure to check the correctness of
     CFI stack frames at build time.  CFI debuginfo is notoriously
     unreliable and we cannot use it in the kernel as-is without extra
     checking done both on the kernel side and on the build side.

  The quality of kernel stack frames matters to debuggability as well,
  so IMO we can merge this without having to consider the live patching
  or CFI debuginfo angle"

* 'core-objtool-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits)
  objtool: Only print one warning per function
  objtool: Add several performance improvements
  tools: Copy hashtable.h into tools directory
  objtool: Fix false positive warnings for functions with multiple switch statements
  objtool: Rename some variables and functions
  objtool: Remove superflous INIT_LIST_HEAD
  objtool: Add helper macros for traversing instructions
  objtool: Fix false positive warnings related to sibling calls
  objtool: Compile with debugging symbols
  objtool: Detect infinite recursion
  objtool: Prevent infinite recursion in noreturn detection
  objtool: Detect and warn if libelf is missing and don't break the build
  tools: Support relative directory path for 'O='
  objtool: Support CROSS_COMPILE
  x86/asm/decoder: Use explicitly signed chars
  objtool: Enable stack metadata validation on 64-bit x86
  objtool: Add CONFIG_STACK_VALIDATION option
  objtool: Add tool to perform compile-time stack metadata validation
  x86/kprobes: Mark kretprobe_trampoline() stack frame as non-standard
  sched: Always inline context_switch()
  ...
Merge git://www.linux-watchdog.org/linux-watchdog 2016-03-20T02:35:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-03-20T02:35:51+00:00 1e75a9f34a5ed5902707fb74b468356c55142b71 Pull watchdog updates from Wim Van Sebroeck: - new drivers for: NI 903x/913x watchdog driver, WinSystems EBC-C384 watchdog timer and ARM SBSA watchdog driver - Support for NCT6102D devices - Improvements of the generic watchdog framework (improve restart handler, make set_timeout optional, introduce infrastructure triggered keepalives, ... - improvements on the pnx4008 watchdog driver - several smaller fixes and improvements * git://www.linux-watchdog.org/linux-watchdog: (28 commits) watchdog: Ensure that wdd is not dereferenced if NULL watchdog: imx2: Convert to use infrastructure triggered keepalives watchdog: dw_wdt: Convert to use watchdog infrastructure watchdog: Add support for minimum time between heartbeats watchdog: Make stop function optional watchdog: Introduce WDOG_HW_RUNNING flag watchdog: Introduce hardware maximum heartbeat in watchdog core watchdog: Make set_timeout function optional arm: lpc32xx: remove restart handler arm: lpc32xx: phy3250 remove restart hook watchdog: pnx4008: restart: support "cmd" from userspace watchdog: pnx4008: add support for soft reset watchdog: pnx4008: add restart handler watchdog: pnx4008: update logging during power-on watchdog: tangox_wdt: test clock rate to avoid division by 0 watchdog: atlas7_wdt: test clock rate to avoid division by 0 watchdog: s3c2410_wdt: Add max and min timeout values Watchdog: introduce ARM SBSA watchdog driver Documentation: add sbsa-gwdt driver documentation watchdog: Add watchdog timer support for the WinSystems EBC-C384 ... 
Pull watchdog updates from Wim Van Sebroeck:

 - new drivers for: NI 903x/913x watchdog driver, WinSystems EBC-C384
   watchdog timer and ARM SBSA watchdog driver

 - Support for NCT6102D devices

 - Improvements of the generic watchdog framework (improve restart
   handler, make set_timeout optional, introduce infrastructure
   triggered keepalives, ...

 - improvements on the pnx4008 watchdog driver

 - several smaller fixes and improvements

* git://www.linux-watchdog.org/linux-watchdog: (28 commits)
  watchdog: Ensure that wdd is not dereferenced if NULL
  watchdog: imx2: Convert to use infrastructure triggered keepalives
  watchdog: dw_wdt: Convert to use watchdog infrastructure
  watchdog: Add support for minimum time between heartbeats
  watchdog: Make stop function optional
  watchdog: Introduce WDOG_HW_RUNNING flag
  watchdog: Introduce hardware maximum heartbeat in watchdog core
  watchdog: Make set_timeout function optional
  arm: lpc32xx: remove restart handler
  arm: lpc32xx: phy3250 remove restart hook
  watchdog: pnx4008: restart: support "cmd" from userspace
  watchdog: pnx4008: add support for soft reset
  watchdog: pnx4008: add restart handler
  watchdog: pnx4008: update logging during power-on
  watchdog: tangox_wdt: test clock rate to avoid division by 0
  watchdog: atlas7_wdt: test clock rate to avoid division by 0
  watchdog: s3c2410_wdt: Add max and min timeout values
  Watchdog: introduce ARM SBSA watchdog driver
  Documentation: add sbsa-gwdt driver documentation
  watchdog: Add watchdog timer support for the WinSystems EBC-C384
  ...
watchdog: Ensure that wdd is not dereferenced if NULL 2016-03-16T20:11:50+00:00 Guenter Roeck linux@roeck-us.net 2016-03-09T02:46:13+00:00 d1ed3ba4e3d76b4ebec239c64f990c26d7935700 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> 
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>
watchdog: imx2: Convert to use infrastructure triggered keepalives 2016-03-16T20:11:23+00:00 Guenter Roeck linux@roeck-us.net 2016-02-28T21:12:20+00:00 11d7aba9ceb726d86aaaca3eb5f7d79de38989c5 The watchdog infrastructure now supports handling watchdog keepalive if the watchdog is running while the watchdog device is closed. Convert the driver to use this infrastructure. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> 
The watchdog infrastructure now supports handling watchdog keepalive
if the watchdog is running while the watchdog device is closed.
Convert the driver to use this infrastructure.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: dw_wdt: Convert to use watchdog infrastructure 2016-03-16T20:11:21+00:00 Guenter Roeck linux@roeck-us.net 2016-02-28T21:12:19+00:00 f29a72c24ad4927027e77e4eed431a61bc8335b2 Convert driver to use watchdog infrastructure. This includes infrastructure support to handle watchdog keepalive if the watchdog is running while the watchdog device is closed. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> 
Convert driver to use watchdog infrastructure. This includes
infrastructure support to handle watchdog keepalive if the watchdog
is running while the watchdog device is closed.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
watchdog: Add support for minimum time between heartbeats 2016-03-16T20:11:19+00:00 Guenter Roeck linux@roeck-us.net 2016-02-28T21:12:18+00:00 15013ad813f6544be8e79afc23672745950d59bc 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> 
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>
watchdog: Make stop function optional 2016-03-16T20:11:16+00:00 Guenter Roeck linux@roeck-us.net 2016-02-28T21:12:17+00:00 d0684c8a9354953efdea214b437445c00743cf49 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> 
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>