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

watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling

2024-01-25T22:34:28+00:00

[ Upstream commit f33f5b1fd1be5f5106d16f831309648cb0f1c31d ]

Users report about the unexpected behavior for setting timeouts above
15 sec on Raspberry Pi. According to watchdog-api.rst the ioctl
WDIOC_SETTIMEOUT shouldn't fail because of hardware limitations.
But looking at the code shows that max_timeout based on the
register value PM_WDOG_TIME_SET, which is the maximum.

Since 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat
in watchdog core") the watchdog core is able to handle this problem.

This fix has been tested with watchdog-test from selftests.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217374
Fixes: 664a39236e71 ("watchdog: Introduce hardware maximum heartbeat in watchdog core")
Signed-off-by: Stefan Wahren 
Reviewed-by: Florian Fainelli 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20231112173251.4827-1-wahrenst@gmx.net
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO

2024-01-25T22:34:28+00:00

[ Upstream commit dced0b3e51dd2af3730efe14dd86b5e3173f0a65 ]

Avoid unnecessary crashes by claiming only NMIs that are due to
ERROR signalling or generated by the hpwdt hardware device.

The code does this, but only for iLO5.

The intent was to preserve legacy, Gen9 and earlier, semantics of
using hpwdt for error containtment as hardware/firmware would signal
fatal IO errors as an NMI with the expectation of hpwdt crashing
the system.  Howerver, these IO errors should be received by hpwdt
as an NMI_IO_CHECK.  So the test is overly permissive and should
not be limited to only ilo5.

We need to enable this protection for future iLOs not matching the
current PCI IDs.

Fixes: 62290a5c194b ("watchdog: hpwdt: Claim NMIs generated by iLO5")
Signed-off-by: Jerry Hoemann 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20231213215340.495734-2-jerry.hoemann@hpe.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: set cdev owner before adding

2024-01-25T22:34:28+00:00

[ Upstream commit 38d75297745f04206db9c29bdd75557f0344c7cc ]

When the new watchdog character device is registered, it becomes
available for opening. This creates a race where userspace may open the
device before the character device's owner is set. This results in an
imbalance in module_get calls as the cdev_get in cdev_open will not
increment the reference count on the watchdog driver module.

This causes problems when the watchdog character device is released as
the module loader's reference will also be released. This makes it
impossible to open the watchdog device later on as it now appears that
the module is being unloaded. The open will fail with -ENXIO from
chrdev_open.

The legacy watchdog device will fail with -EBUSY from the try_module_get
in watchdog_open because it's module owner is the watchdog core module
so it can still be opened but it will fail to get a refcount on the
underlying watchdog device driver.

Fixes: 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev")
Signed-off-by: Curtis Klein 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20231205190522.55153-1-curtis.klein@hpe.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: iTCO_wdt: Set NO_REBOOT if the watchdog is not already running

2023-10-10T19:46:40+00:00

commit ef9b7bf52c2f47f0a9bf988543c577b92c92d15e upstream.

Daniel reported that the commit 1ae3e78c0820 ("watchdog: iTCO_wdt: No
need to stop the timer in probe") makes QEMU implementation of the iTCO
watchdog not to trigger reboot anymore when NO_REBOOT flag is initially
cleared using this option (in QEMU command line):

  -global ICH9-LPC.noreboot=false

The problem with the commit is that it left the unconditional setting of
NO_REBOOT that is not cleared anymore when the kernel keeps pinging the
watchdog (as opposed to the previous code that called iTCO_wdt_stop()
that cleared it).

Fix this so that we only set NO_REBOOT if the watchdog was not initially
running.

Fixes: 1ae3e78c0820 ("watchdog: iTCO_wdt: No need to stop the timer in probe")
Reported-by: Daniel P. Berrangé 
Signed-off-by: Mika Westerberg 
Tested-by: Daniel P. Berrangé 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20221028062750.45451-1-mika.westerberg@linux.intel.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: iTCO_wdt: No need to stop the timer in probe

2023-10-10T19:46:40+00:00

commit 1ae3e78c08209ac657c59f6f7ea21bbbd7f6a1d4 upstream.

The watchdog core can handle pinging of the watchdog before userspace
opens the device. For this reason instead of stopping the timer, just
mark it as running and let the watchdog core take care of it.

Cc: Malin Jonsson 
Signed-off-by: Mika Westerberg 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20210921102900.61586-1-mika.westerberg@linux.intel.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: intel-mid_wdt: add MODULE_ALIAS() to allow auto-load

2023-09-23T08:59:58+00:00

[ Upstream commit cf38e7691c85f1b09973b22a0b89bf1e1228d2f9 ]

When built with CONFIG_INTEL_MID_WATCHDOG=m, currently the driver
needs to be loaded manually, for the lack of module alias.
This causes unintended resets in cases where watchdog timer is
set-up by bootloader and the driver is not explicitly loaded.
Add MODULE_ALIAS() to load the driver automatically at boot and
avoid this issue.

Fixes: 87a1ef8058d9 ("watchdog: add Intel MID watchdog driver support")
Signed-off-by: Raag Jadav 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230811120220.31578-1-raag.jadav@intel.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: menz069_wdt: fix watchdog initialisation

2023-06-09T08:28:55+00:00

[ Upstream commit 87b22656ca6a896d0378e9e60ffccb0c82f48b08 ]

Doing a 'cat /dev/watchdog0' with menz069_wdt as watchdog0 will result in
a NULL pointer dereference.

This happens because we're passing the wrong pointer to
watchdog_register_device(). Fix this by getting rid of the static
watchdog_device structure and use the one embedded into the driver's
per-instance private data.

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230418172531.177349-2-jth@kernel.org
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin

watchdog: sp5100_tco: Immediately trigger upon starting.

2023-05-30T11:44:08+00:00

commit 4eda19cc8a29cde3580ed73bf11dc73b4e757697 upstream.

The watchdog countdown is supposed to begin when the device file is
opened. Instead, it would begin countdown upon the first write to or
close of the device file. Now, the ping operation is called within the
start operation which ensures the countdown begins. From experimenation,
it does not appear possible to do this with a single write including
both the start bit and the trigger bit. So, it is done as two distinct
writes.

Signed-off-by: Gregory Oakes 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230316201312.17538-1-gregory.oakes@amd.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Cc: Mario Limonciello 
Signed-off-by: Greg Kroah-Hartman

watchdog: sbsa_wdog: Make sure the timeout programming is within the limits

2023-04-20T10:07:37+00:00

commit 000987a38b53c172f435142a4026dd71378ca464 upstream.

Make sure to honour the max_hw_heartbeat_ms while programming the timeout
value to WOR. Clamp the timeout passed to sbsa_gwdt_set_timeout() to
make sure the programmed value is within the permissible range.

Fixes: abd3ac7902fb ("watchdog: sbsa: Support architecture version 1")

Signed-off-by: George Cherian 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230209021117.1512097-1-george.cherian@marvell.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Tyler Hicks (Microsoft) 
Signed-off-by: Greg Kroah-Hartman

watchdog: pcwd_usb: Fix attempting to access uninitialized memory

2023-03-11T15:44:11+00:00

[ Upstream commit 7d06c07c67100fd0f8e6b3ab7145ce789f788117 ]

The stack variable msb and lsb may be used uninitialized in function
usb_pcwd_get_temperature and usb_pcwd_get_timeleft when usb card no response.

The build waring is:
drivers/watchdog/pcwd_usb.c:336:22: error: ‘lsb’ is used uninitialized in this function [-Werror=uninitialized]
  *temperature = (lsb * 9 / 5) + 32;
                  ~~~~^~~
drivers/watchdog/pcwd_usb.c:328:21: note: ‘lsb’ was declared here
  unsigned char msb, lsb;
                     ^~~
cc1: all warnings being treated as errors
scripts/Makefile.build:250: recipe for target 'drivers/watchdog/pcwd_usb.o' failed
make[3]: *** [drivers/watchdog/pcwd_usb.o] Error 1

Fixes: b7e04f8c61a4 ("mv watchdog tree under drivers")
Signed-off-by: Li Hua 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20221116020706.70847-1-hucool.lihua@huawei.com
Signed-off-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Signed-off-by: Sasha Levin