[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1435324873-18318-1-git-send-email-abbotti@mev.co.uk>
Date: Fri, 26 Jun 2015 14:21:08 +0100
From: Ian Abbott <abbotti@....co.uk>
To: linux-watchdog@...r.kernel.org
Cc: Wim Van Sebroeck <wim@...ana.be>, linux-kernel@...r.kernel.org
Subject: [PATCH 0/5] watchdog: dw_wdt: allow only one probe + various fixes
The dw_wdt watchdog driver supports a single DesignWare watchdog device
using a statically allocated variable 'dw_wdt' to manage it, but there
are some bits of hardware containing two such devices. If the "probe"
is called for more than one device, the 'dw_wdt' variable gets
clobbered, generally resulting in a kernel crash. Change it to reject
additional probed devices.
We probably don't expect the "remove" function to get called, but if it
does, make sure the Linux timer used by device gets unqueued.
The timer also gets unqueued if the watchdog device is closed by the
user process unexpectedly. However, this is not currently done
asynchronously and the timer function normally requeues the timer. If
it manages to requeue the timer, the next call of the timer function
will behave as though the close was expected and continue patting the
dog every half a second when it should have stopped doing so. Unqueue
the timer synchronously to avoid that.
NOTE: There is another potential problem that I haven't bothered to fix.
If the "remove" function is called while the watchdog device is still
open, any in-progress or future file operations are likely to screw
things up.
1) watchdog: dw_wdt: prepare for more atomic bits
2) watchdog: dw_wdt: reject additional device probes
3) watchdog: dw_wdt: only unregister restart handler if registered
4) watchdog: dw_wdt: unqueue timer on device removal
5) watchdog: dw_wdt: unqueue timer synchronously on unexpected close
drivers/watchdog/dw_wdt.c | 46 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 35 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists