linux-stable.git/drivers/watchdog, branch v5.4.151

Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout"

2021-08-08T07:04:08+00:00

This reverts commit f58ab0b02ee7b095e0cae4ba706caa86fff5557b which is
commit cb011044e34c293e139570ce5c01aed66a34345c upstream.

It is reported to cause problems with systems and probably should not
have been backported in the first place :(

Link: https://lore.kernel.org/r/20210803165108.4154cd52@endymion
Reported-by: Jean Delvare 
Cc: Jan Kiszka 
Cc: Guenter Roeck 
Cc: Guenter Roeck 
Cc: Wim Van Sebroeck 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

watchdog: aspeed: fix hardware timeout calculation

2021-07-20T14:10:49+00:00

[ Upstream commit e7dc481c92060f9ce872878b0b7a08c24713a7e5 ]

Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
ensure the reload value does not exceed the hardware limit.

Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad 
Signed-off-by: Tao Ren 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20210417034249.5978-1-rentao.bupt@gmail.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: iTCO_wdt: Account for rebooting on second timeout

2021-07-20T14:10:47+00:00

[ Upstream commit cb011044e34c293e139570ce5c01aed66a34345c ]

This was already attempted to fix via 1fccb73011ea: If the BIOS did not
enable TCO SMIs, the timer definitely needs to trigger twice in order to
cause a reboot. If TCO SMIs are on, as well as SMIs in general, we can
continue to assume that the BIOS will perform a reboot on the first
timeout.

QEMU with its ICH9 and related BIOS falls into the former category,
currently taking twice the configured timeout in order to reboot the
machine. For iTCO version that fall under turn_SMI_watchdog_clear_off,
this is also true and was currently only addressed for v1, irrespective
of the turn_SMI_watchdog_clear_off value.

Signed-off-by: Jan Kiszka 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/0b8bb307-d08b-41b5-696c-305cdac6789c@siemens.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: imx_sc_wdt: fix pretimeout

2021-07-20T14:10:47+00:00

[ Upstream commit 854478a381078ee86ae2a7908a934b1ded399130 ]

If the WDIOF_PRETIMEOUT flag is not set when registering the device the
driver will not show the sysfs entries or register the default governor.
By moving the registering after the decision whether pretimeout is
supported this gets fixed.

Signed-off-by: Stefan Eichenberger 
Reviewed-by: Guenter Roeck 
Reviewed-by: Dong Aisheng 
Link: https://lore.kernel.org/r/20210519080311.142928-1-eichest@gmail.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: Fix possible use-after-free by calling del_timer_sync()

2021-07-20T14:10:47+00:00

[ Upstream commit d0212f095ab56672f6f36aabc605bda205e1e0bf ]

This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.

Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
Reviewed-by: Guenter Roeck 
Acked-by: Vladimir Zapolskiy 
Link: https://lore.kernel.org/r/1620802676-19701-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()

2021-07-20T14:10:47+00:00

[ Upstream commit 90b7c141132244e8e49a34a4c1e445cce33e07f4 ]

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.

Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/1620716691-108460-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: Fix possible use-after-free in wdt_startup()

2021-07-20T14:10:47+00:00

[ Upstream commit c08a6b31e4917034f0ed0cb457c3bb209576f542 ]

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.

Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/1620716495-108352-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: mei_wdt: request stop on unregister

2021-03-04T09:26:47+00:00

commit 740c0a57b8f1e36301218bf549f3c9cc833a60be upstream.

The MEI bus has a special behavior on suspend it destroys
all the attached devices, this is due to the fact that also
firmware context is not persistent across power flows.

If watchdog on MEI bus is ticking before suspending the firmware
times out and reports that the OS is missing watchdog tick.
Send the stop command to the firmware on watchdog unregistered
to eliminate the false event on suspend.
This does not make the things worse from the user-space perspective
as a user-space should re-open watchdog device after
suspending before this patch.

Cc: 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20210124114938.373885-1-tomas.winkler@intel.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Greg Kroah-Hartman

watchdog: qcom: Remove incorrect usage of QCOM_WDT_ENABLE_IRQ

2021-03-04T09:26:47+00:00

commit a4f3407c41605d14f09e490045d0609990cd5d94 upstream.

As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
of watchdog control register is wakeup interrupt enable bit and
not related to bark interrupt at all, BIT(0) is used for that.
So remove incorrect usage of this bit when supporting bark irq for
pre-timeout notification. Currently with this bit set and bark
interrupt specified, pre-timeout notification and/or watchdog
reset/bite does not occur.

Fixes: 36375491a439 ("watchdog: qcom: support pre-timeout when the bark irq is available")
Cc: stable@vger.kernel.org
Signed-off-by: Sai Prakash Ranjan 
Reviewed-by: Guenter Roeck 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20210126150241.10009-1-saiprakash.ranjan@codeaurora.org
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Greg Kroah-Hartman

watchdog: coh901327: add COMMON_CLK dependency

2020-12-30T10:51:28+00:00

[ Upstream commit 36c47df85ee8e1f8a35366ac11324f8875de00eb ]

clang produces a build failure in configurations without COMMON_CLK
when a timeout calculation goes wrong:

arm-linux-gnueabi-ld: drivers/watchdog/coh901327_wdt.o: in function `coh901327_enable':
coh901327_wdt.c:(.text+0x50): undefined reference to `__bad_udelay'

Add a Kconfig dependency to only do build testing when COMMON_CLK
is enabled.

Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20201203223358.1269372-1-arnd@kernel.org
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin