Patch busybox watchdog to fix restarts

It is possible the watchdog device is configured to do
something other than reset the system on a watchdog timeout.
If this occurs, and the busybox watchdog is started back up again,
the watchdog driver won't actually start the watchdog hardware
unless the watchdog device has been properly closed first.

So, on startup, write the magic character to the watchdog
device to properly close it before running.

Change-Id: I61521d337a958c9dc8f9a6786a65aee3e81994ac
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

2 files changed, 64 insertions, 0 deletions

diff --git a/meta-phosphor/common/recipes-core/busybox/busybox/0001-Stop-watchdog-first-on-startup.patch b/meta-phosphor/common/recipes-core/busybox/busybox/0001-Stop-watchdog-first-on-startup.patch
new file mode 100644
index 000000000..7128b8108
--- /dev/null
+++ b/meta-phosphor/common/recipes-core/busybox/busybox/0001-Stop-watchdog-first-on-startup.patch
@@ -0,0 +1,63 @@
+From a4c493ae42926ab36fdc805a5da9f0682bb98b45 Mon Sep 17 00:00:00 2001
+From: Matt Spinler <spinler@us.ibm.com>
+Date: Tue, 13 Jun 2017 15:26:49 -0500
+Subject: [PATCH] Stop watchdog first on startup
+
+Some watchdog implementations may do things other than issue
+a reboot on a watchdog timeout.  In this case, there's the
+possibility of restarting this program from the state of
+the watchdog device not being properly stopped (done by writing
+a 'V' and closing the device).  Since it wasn't stopped, the
+driver may not be able to restart the watchdog when this program
+reopens it and starts pinging it.
+
+To fix this, the code will always first issue the stop when it
+starts up.
+
+Signed-off-by: Matt Spinler <spinler@us.ibm.com>
+---
+ miscutils/watchdog.c | 21 +++++++++++++++++++--
+ 1 file changed, 19 insertions(+), 2 deletions(-)
+
+diff --git a/miscutils/watchdog.c b/miscutils/watchdog.c
+index 07ae64e52..223e3c32d 100644
+--- a/miscutils/watchdog.c
++++ b/miscutils/watchdog.c
+@@ -53,6 +53,24 @@ static void watchdog_shutdown(int sig UNUSED_PARAM)
+ 	_exit(EXIT_SUCCESS);
+ }
+ 
++static void watchdog_open(const char* device)
++{
++	static const char magic_value = 'V';
++
++	/* If the watchdog driver can do something other than cause a reboot
++	 * on a timeout, then it's possible this program may be starting from
++	 * a state when the watchdog hadn't been previously stopped with
++	 * the magic write followed by a close.  In this case the driver may
++	 * not start properly, so always do the proper stop first just in case.
++	 */
++
++	/* Use known fd # - avoid needing global 'int fd' */
++	xmove_fd(xopen(device, O_WRONLY), 3);
++	write(3, &magic_value, 1);
++	close(3);
++	xmove_fd(xopen(device, O_WRONLY), 3);
++}
++
+ int watchdog_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
+ int watchdog_main(int argc, char **argv)
+ {
+@@ -88,8 +106,7 @@ int watchdog_main(int argc, char **argv)
+ 
+ 	bb_signals(BB_FATAL_SIGS, watchdog_shutdown);
+ 
+-	/* Use known fd # - avoid needing global 'int fd' */
+-	xmove_fd(xopen(argv[argc - 1], O_WRONLY), 3);
++	watchdog_open(argv[argc - 1]);
+ 
+ 	/* WDIOC_SETTIMEOUT takes seconds, not milliseconds */
+ 	htimer_duration = htimer_duration / 1000;
+-- 
+2.11.0
+
diff --git a/meta-phosphor/common/recipes-core/busybox/busybox_%.bbappend b/meta-phosphor/common/recipes-core/busybox/busybox_%.bbappend
index 3c4f2b61f..39a6033f7 100644
--- a/meta-phosphor/common/recipes-core/busybox/busybox_%.bbappend
+++ b/meta-phosphor/common/recipes-core/busybox/busybox_%.bbappend
@@ -1,3 +1,4 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 SRC_URI += "file://busybox.cfg"
 SRC_URI += "file://flash.cfg"
+SRC_URI += "file://0001-Stop-watchdog-first-on-startup.patch"