- 21 Jan, 2018 10 commits
-
-
Guenter Roeck authored
Match PCI device in module init function, not in the probe function. It is pointless trying to probe if we can determine early that the device is not supported. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be>
-
Guenter Roeck authored
There are too many unnecessary goto statements in sp5100_tco_setupdevice(). Rearrange the code and limit goto statements to error handling. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
-
Guenter Roeck authored
By using standard error codes, we can identify and return more than one error condition. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
-
Guenter Roeck authored
Use request_muxed_region for multiplexed IO memory regions. Also, SP5100_IO_PM_INDEX_REG/SP5100_IO_PM_DATA_REG are only used during initialization; it is unnecessary to keep the address range reserved. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
-
Guenter Roeck authored
According to all published information, the watchdog disable bit for SB800 compatible controllers is bit 1 of PM register 0x48, not bit 2. For the most part that doesn't matter in practice, since the bit has to be cleared to enable watchdog address decoding, which is the default setting, but it still needs to be fixed. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
-
Guenter Roeck authored
SP5100_IO_PM_INDEX_REG and SB800_IO_PM_INDEX_REG are used inconsistently and define the same value. Just use SP5100_IO_PM_INDEX_REG throughout. Do the same for SP5100_IO_PM_DATA_REG and SB800_IO_PM_DATA_REG. Use helper functions to access the indexed registers. Cc: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by:
-
Christophe Leroy authored
commit 4cd13c21 ("softirq: Let ksoftirqd do its job") has the effect of deferring timer handling in case of high CPU load, hence delaying the delayed work allthought the worker is running which high realtime priority. As hrtimers are not managed by softirqs, this patch replaces the delayed work by a plain work and uses an hrtimer to schedule that work. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
-
André Draszik authored
This does the necessary cleanup on driver unload automatically. Signed-off-by:
André Draszik <git@andred.net> Cc: linux-watchdog@vger.kernel.org Cc: John Crispin <john@phrozen.org> Reviewed-by:
-
André Draszik authored
If the watchdog hardware is enabled/running during boot, e.g. due to a boot loader configuring it, we must tell the watchdog framework about this fact so that it can ping the watchdog until userspace opens the device and takes over control. Do so using the WDOG_HW_RUNNING flag that exists for exactly that use-case. Given the watchdog driver core doesn't know what timeout was originally set by whoever started the watchdog (boot loader), we make sure to update the timeout in the hardware according to what the watchdog core thinks it is. Signed-off-by:
-
Martin Kaiser authored
When the watchdog device is suspended, its timeout is set to the maximum value. During resume, the previously set timeout should be restored. This does not work at the moment. The suspend function calls imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME); and resume reverts this by calling imx2_wdt_set_timeout(wdog, wdog->timeout); However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore, wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume function. Fix this by adding a new function __imx2_wdt_set_timeout() which only updates the hardware settings. imx2_wdt_set_timeout() now calls __imx2_wdt_set_timeout() and then saves the new timeout to wdog->timeout. During suspend, we call __imx2_wdt_set_timeout() directly so that wdog->timeout won't be updated and we can restore the previous value during resume. This approach makes wdog->timeout different from the actual setting in the hardware which is usually not a good thing. However, the two differ only while we're suspended and no kernel code is running, so it should be ok in this case. Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Cc: stable@vger.kernel.org Reviewed-by:
-
- 28 Dec, 2017 30 commits
-
-
Christophe Leroy authored
When running a command like 'chrt -f 50 dd if=/dev/zero of=/dev/null', the watchdog_worker fails to service the HW watchdog and the HW watchdog fires long before the watchdog soft timeout. At the moment, the watchdog_worker is invoked as a delayed work. Delayed works are handled by non realtime kernel threads. The WQ_HIGHPRI flag only increases the niceness of that threads. This patch replaces the delayed work logic by kthread delayed work, and sets the associated kernel task to SCHED_FIFO with the highest priority, in order to ensure that the watchdog worker will run as soon as possible. Signed-off-by:
-
David Lechner authored
This adds a restart function to the davinci watchdog timer driver. This is copied from arch/arm/mach-davinci/time.c and will allow us to remove the code from there. Signed-off-by:
David Lechner <david@lechnology.com> Reviewed-by:
-
Corentin Labbe authored
All parameters of watchdog_init_timeout() are documented with exception of wdd, thus generating a build warning. This patch document it and so remove the following build warning: drivers/watchdog/watchdog_core.c:113: warning: No description found for parameter 'wdd' Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Reviewed-by:
-
Arnd Bergmann authored
The new hpwdt_my_nmi() function is used conditionally, which produces a harmless warning in some configurations: drivers/watchdog/hpwdt.c:478:12: error: 'hpwdt_my_nmi' defined but not used [-Werror=unused-function] This moves it inside of the #ifdef that protects its caller, to silence the warning. Fixes: 621174a92851 ("watchdog: hpwdt: Check source of NMI") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jerry Hoemann <jerry.hoemann@hpe.com> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Benjamin Gaignard authored
Uniformize STMicroelectronics copyrights header Add SPDX identifier Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
Alexandre TORGUE <alexandre.torgue@st.com> CC: Yannick Fertre <yannick.fertre@st.com> Acked-by:
Yannick Fertre <yannick.fertre@st.com> Reviewed-by:
-
Greg Kroah-Hartman authored
There is no need to #define the license of the driver, just put it in the MODULE_LICENSE() line directly as a text string. This allows tools that check that the module license matches the source code license to work properly, as there is no need to unwind the unneeded dereference, especially when it is defined just a few lines above from where it is used. Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Guenter Roeck <linux@roeck-us.net> Reported-by:
Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
Radu Rendec authored
The initial info message (early in the xen_wdt_init_module() function) is not very useful and we already have a message on successful probe. If the probe fails, additional messages are printed anyway. The version number serves no useful purpose and it ran out of favor upstream anyway. Signed-off-by:
Radu Rendec <rrendec@arista.com> Reviewed-by:
-
Radu Rendec authored
Change the xen_wdt driver to use the watchdog subsystem instead of registering and manipulating the char device directly through the misc API. This is mainly getting rid of the "write" and "ioctl" methods and part of the watchdog control logic (which are all implemented by the watchdog subsystem). Even though the watchdog subsystem supports registering and handling multiple watchdog devices at the same time, the xen_wdt driver has an inherent limitation of only one device due to the way the Xen hypervisor exposes watchdog functionality. However, the driver can now coexist with other watchdog devices (supported by different drivers). Signed-off-by:
-
Eric Long authored
This patch adds the watchdog driver for Spreadtrum SC9860 platform. Signed-off-by:
Eric Long <eric.long@spreadtrum.com> Reviewed-by:
-
Eric Long authored
This patch adds the documentation for Spreadtrum watchdog driver. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Christophe Leroy authored
The watchdog core includes a worker function which pings the watchdog until user app starts pinging it and which also pings it if the HW require more frequent pings. Use that function instead of the dedicated timer. In the mean time, we can allow the user to change the timeout. Then change the timeout module parameter to use seconds and use the watchdog_init_timeout() core function. On some HW (eg: the 8xx), SWCRR contains bits unrelated to the watchdog which have to be preserved upon write. This driver has nothing preventing the use of the magic close, so enable it. Signed-off-by:
-
Rasmus Villemoes authored
The first patch above (https://patchwork.kernel.org/patch/9970181/) makes the oops go away, but it just papers over the problem. The real problem is that the watchdog core clears WDOG_HW_RUNNING in watchdog_stop, and the gpio driver fails to set it in its stop function when it doesn't actually stop it. This means that the core doesn't know that it now has responsibility for petting the device, in turn causing the device to reset the system (I hadn't noticed this because the board I'm working on has that reset logic disabled). How about this (other drivers may of course have the same problem, I haven't checked). One might say that ->stop should return an error when the device can't be stopped, but OTOH this brings parity between a device without a ->stop method and a GPIO wd that has always-running set. IOW, I think ->stop should only return an error when an actual attempt to stop the hardware failed. From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> The watchdog framework clears WDOG_HW_RUNNING before calling ->stop. If the driver is unable to stop the device, it is supposed to set that bit again so that the watchdog core takes care of sending heart-beats while the device is not open from user-space. Update the gpio_wdt driver to honour that contract (and get rid of the redundant clearing of WDOG_HW_RUNNING). Fixes: 3c10bbde ("watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function") Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I replaced "Fall" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
Geert Uytterhoeven authored
Document support for the Watchdog Timer (WDT) Controller in the Renesas R-Car V3M (r8a77970) SoC. Restore sort order while at it. No driver update is needed. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Tomas Winkler authored
Fixes sparse warning: drivers/watchdog/mei_wdt.c:530:18: warning: Variable length array is used Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by:
-
Radu Rendec authored
The initial info message (early in the esb_probe() function) is not very useful and we already have a message on successful probe, which includes device identification. If the probe fails (e.g. PCI related errors), additional messages are printed anyway. The version number was only used in the initial info message. Other than that, it serves no useful purpose and it ran out of favor upstream anyway. Signed-off-by:
-
Radu Rendec authored
The minimum, maximum and default values for the watchdog heartbeat (timeout) were hardcoded in several places (including module parameter description and warning message for invalid module parameter value). This patch adds macros for the aforementioned values and replaces all occurences of hardcoded values by these macros. Signed-off-by:
-
Radu Rendec authored
Support multiple i6300esb devices simultaneously, by removing the single device restriction in the original design and leveraging the multiple device support of the watchdog subsystem. This patch replaces the global definitions of watchdog device data with a dynamically allocated structure. This structure is allocated during device probe, so multiple independent structures can be allocated if multiple devices are probed. Signed-off-by:
-
Radu Rendec authored
Change the i6300esb driver to use the watchdog subsystem instead of the legacy watchdog API. This is mainly just getting rid of the "write" and "ioctl" methods and part of the watchdog control logic (which are all implemented by the watchdog subsystem). Even though the watchdog subsystem supports registering and handling multiple watchdog devices at the same time, the i6300esb driver still has a limitation of only one i6300esb device due to some global variable usage that comes from the original design. However, the driver can now coexist with other watchdog devices (supported by different drivers). Signed-off-by:
-
Jerry Hoemann authored
Do not claim the NMI (i.e. return NMI_DONE) if the source of the NMI isn't the iLO watchdog or debug. Signed-off-by:
-
Corentin Labbe authored
The usage of of_device_get_match_data reduce the code size a bit. Furthermore, it prevents an improbable dereference when of_match_device() return NULL. Signed-off-by:
-
Arnd Bergmann authored
The Xen watchdog driver uses __kernel_time_t and ktime_to_timespec() internally for managing its timeouts. Both are deprecated because of y2038 problems. The driver itself is fine, since it only uses monotonic times, but converting it to use ktime_get_seconds() avoids the deprecated interfaces and is slightly simpler. Signed-off-by:
-
