Merge branch 'for-next/watchdog'

Merge branch 'for-next/misc'

watchdog: add support for at91sam9/sama5 watchdog ...

The watchdog on these SoCs is enabled by default on system boot, so a
driver is especially useful. According to data sheet the mode register
containing the timeout can be configured only once, but I couldn't
verify this on the sama5d2. Regardless, the driver takes care not to
change the mode register unless necessary. Implementation that want to
leave to the OS the decision which timeout to choose, can just keep
pinging with the POR-default of 16 seconds and the OS will be able to
set the final timeout.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

treewide: make use of PTR_ERR_OR_ZERO ...

PTR_ERR_OR_ZERO is designed to replace boiler plate like:

	if (IS_ERR(x))
		return PTR_ERR(x);
	return 0;

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

startup: inhibit watchdogs on non-interactive autoboot abort ...

nv.autoboot=abort has been added as development aid to have barebox stop
at the shell prompt automatically. It makes sense to inhibit all watchdogs
in this mode, so the user can later use the shell in peace.

This also applies to fastboot aborting the shell prompt. If this
happens, watchdog will be automatically inhibited as well.
Behavior on user aborting the shell prompt via keypad or uart input
remains unchanged for backwards-compatibility.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: permit `wd 0` for non-stoppable, but inactive, watchdogs ...

A watchdog that can't be stopped returns -ENOSYS on set_timeout(0).
If the watchdog supports communicating whether it's running, we could
still allow `wd 0`, if it hasn't been started yet.

Setting device parameter .priority=0 disables a watchdog. One would
expect this to always succeed for a not-running watchdog, but currently
it doesn't, if the driver's set_timeout(0) returns -ENOSYS. With this
fix, this is supported making the user API less surprising.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: f71808e: maintain watchdog timeout occurred flag ...

If we experience a watchdog reset, the indicating flag should persist
till the Linux driver had a chance to see it.

The flag bit is special however in that writing 1 clears the bit and
writing 0 keeps it intact, i.e. :

Bit
read written  result
  0     0     = 0
  1     0     = 1
  0     1     = 0
  1     1     = 0

So in the bootloader, we should write a zero always. The OS on the
other hand can either write 1 or the old value after reading to
clear the flag.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

poller: Give pollers a name ...

It helps debugging when pollers have a name, so give them one.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/mxs'

drivers: mark first batch of compilable drivers for COMPILE_TEST ...

All of these drivers have a runtime dependency on SoC peripherals, but
can nevertheless be compile-tested. Add COMPILE_TEST as an alternate
dependency.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: i.MX28: Add device tree support ...

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: kvx: Add kvx watchdog support ...

Add a watchdog for kvx architecture based on core watchdog.

Signed-off-by: Clement Leger <cleger@kalray.eu>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

reset: stm32: migrate restart reason and handler from stm32_iwdg ...

The watchdog driver will remain unprobed if the driver or the OF node
is disabled, but the reset reason is useful even then.

System reset and reset source determination is achieved with the RCC
peripheral for which we have a reset controller driver.
Move the code over there, so reset reason and reset are available
always.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

reset_source: migrate from reset_source_name to reset_source_to_string ...

Whether reset_source_name() returns the just set reset_source is
dependent on probe order and the priorities of prior reset sources
in relation to the current one. Make this more robust by using the new
reset_source_to_string.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: f71808e: only print reset reason if one's indicated ...

On most resets, a "reset reason: unknown" would clutter the console,
because the watchdog doesn't support differentiating between POR and
RST. Reduce the clutter by only printing the message when we have
something interesting to say (i.e. watchdog reset).

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: dw_wdt: remove duplicated error message ...

The wd command already warns that "Watchdog cannot be disabled",
when the stop operation returns -ENOSYS. We do that now, so telling the
user that it will not stop is superfluous. Remove it.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: dw_wdt: inform user on missing reset control line ...

The driver has an error message on probe and one on each watchdog stop
attempt that warns the user if the reset line is missing.

Missing reset line (because the "reset"-property is missing) is
indicated by a NULL pointer though, so these warnings were only
triggered when the reset controller specification is malformed.

Fix this by propagating malformed reset pointer specification and
continuing only if it's either valid or completely missing.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: dw_wdt: populate driver_d.name ...

Apparently, somewhere between v2017.01.0 and v2020.01.0, barebox became
dependent on drivers having a name as having this driver enabled in
v2020.01.0 has barebox crash due to a null pointer dereference in the
device_match's second strcmp.

A previous commit introduced a palatable warning for this case.
Now in order to be able to use the driver again, give it a name.

Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: Fix error path ...

In case of an error (e.g. dev_add_param_tristate_ro() returns -ENOSYS),
device registration must be reverted.

Signed-off-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/watchdog'

watchdog: core: use new dev_add_param_tristate helper for .running param ...

Previous commit added a dev_add_param_tristate_ro that can be readily
used instead of the enum parameter here. Use it.
This also fixes the issue that running_names had external linkage.

Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: stm32_iwdg: explicitly set .running to UNSUPPORTED ...

I've spent some time trying to get the ONF (Watchdog enable status)
bit in the IWDG_SR register to read as something other than zero.

It has since been confirmed to be non-functional[1]. To avoid someone
else spending time on this, document that running status is unsupported
on this hardware explicitly.
No functional change as UNSUPPORTED is already the default.

[1]: https://www.spinics.net/lists/arm-kernel/msg770527.html

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: stm32_iwdg: return -ENOSYS on attempt to disable ...

The stm32_iwdg watchdog can't be disabled. To have the wd commant report
this fact correctly to the user, the ->set_timeout needs to return -ENOSYS
which is interpreted as "Watchdog cannot be disabled" instead of -EINVAL
which means "Timeout value out of range".

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

mfd: stpmic1: use register define from header ...

A previous commit has copied over the upstream <linux/mfd/stpmic1.h>
header. Use it instead of replicating register definitions in the
MFD and watchdog cell driver. No functional change.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: f71808e: support .running device parameter ...

The American Megatrends BIOS I am using can be configured to start the
Fintek watchdog prior to the UEFI payloads. To avoid BIOS updates that reset
this functionality going unnoticed, implement support for WDOG_HW_RUNNING.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: imxwd: support .running device parameter on i.MX2+ ...

The i.MX can be fused to start the watchdog on power-on reset.
To give users an easy way to determine whether the watchdog is running,
implement support for WDOG_HW_RUNNING.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: implement generic support for .running device parameter ...

Linux watchdog have an optional WDOG_HW_RUNNING bit that is used in
conjunction with CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED to automatically
ping running watchdogs until userspace takes over.

So far, when we ported Linux drivers, we dropped this detection, but it
would be useful to have this information in barebox as well:

The American Megatrends BIOS I am using allows configuring the hardware
watchdog from the BIOS. barebox enables the WDT as well, so in normal
operation we would never notice if after a BIOS update, the watchdog is
no longer enabled. If we maintain a running parameter on watchdog
devices, board code can be written to check whether the watchdog device
is indeed running.

To achieve this, add the necessary bits to the watchdog API. How we go
about it differs from Linux a little:

- We use an enum instead of a single bit, so we can differentiate between
  watchdogs that are not running and watchdogs whose running status is
  unknown.
- Because we can check whether watchdog_hw_running is supported, it now
  can fail and return a negative value in that case
- We do the maintenance of the running parameter after barebox
  feeds/disables the watchdog in the core, so it doesn't need to
  be replicated across drivers. Drivers hould only initialize the
  running parameter once at probe time.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

watchdog: always populate watchdog priority from device tree if possible ...

So far, only the da9063 and da9053 have made use of the optional barebox
watchdog-priority binding. Move it into the core, so other device
drivers automatically have their watchdog-priority property parsed as
well. This patch doesn't introduce any functional changes for upstream
boards.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Merge branch 'for-next/watchdog'

mfd: stpmic1: use dev_get_regmap instead of priv member ...

When we call regmap_init, the regmap is associated with the device
supplied and can be queried with dev_get_regmap. This is more natural
than expecting cell drivers to cast dev->parent->priv. Do it.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>