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>

watchdog: add timeout_cur parameter only when poller is enabled ...

timeout_curr is the timeout programmed into the watchdog hardware every
500 milliseconds. If watchdog poller support is disabled, it still
shows up as a configurable device parameter, but has no effect.

Improve user experience by having it show up only if watchdog poller
support was compiled in. This is already the case for the autoping
parameter. The timeout_max parameter is a generic parameter and will
remain unchanged.

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

watchdog: rename timeout_curr to poller_timeout_curr internally ...

timeout_curr is the timeout programmed into the watchdog hardware every
500 milliseconds. If watchdog poller support is disabled, it serves
no purpose, prefix it with poller_ to better communicate this fact.

No functional change.

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

watchdog: remove wrong uses of timeout_cur ...

The barebox watchdog poller uses the struct watchdog.timeout_cur as
the timeout value to configure the watchdog with.

There's no need for the device driver to set this. I didn't know that
when I wrote the drivers, but I do now, hence this commit.

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

watchdog: export API to configure watchdogs by name ...

So far watchdog users could only configure the watchdog with the highest
priority. In preparation for having the wd command configure a watchdog
by name, extend watchdog_set_timeout with a struct watchdog *parameter
and export functions to query default watchdog and to find watchdog by
name.
No functional change.

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

watchdog: export priority as device parameter ...

8f4cf30903 ("watchdog: Allow multiple watchdogs") introduced the ability
to set a per-watchdog priority from within drivers, which is usually
populated with of_get_watchdog_priority.

For debugging, it can be useful to query and override this priority on
the fly.  Provide a device parameter to do so.
As watchdog_get_default only considers priorities > 0, it makes sense
to have a newly set priority of 0 disable the watchdog.

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

watchdog: efi: bump down priority below default ...

The barebox EFI documentation notes:

> Current linux kernel (v5.0) will execute ExitBootServices() during the
> early boot stage and thus will automatically disable the (U)EFI watchdog.
> Since it is the proper behavior according to the (U)EFI specification, it
> is impossible to protect full boot chain by using this watchdog only.
> It is recommended to use an alternative hardware watchdog

Heed the advice and bump down the EFI watchdog priority below the
watchdog priority default.
This ensures the EFI watchdog isn't inadvertently used if other
watchdogs are registered.

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

watchdog: add support for Fintek F718xx and, F818xx Super I/O ...

This is an adaptation of the Linux v5.3 f71808e_wdt driver for the watchdog
component of the Fintek Super I/O chips.

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

Merge branch 'for-next/stm32'

watchdog: add support for STPMIC1 integrated watchdog ...

The driver adds support for the PMIC's watchdog, reset, poweroff
and reset reason query capabilities.

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

reset_source: drop reset_source_set_instance() ...

The semantic of reset_source_set_instance() required a separate call to
reset_source_set() (or reset_source_set_priority()) and checked right
usage only using the type. Make the set of functions a bit easier to use
by dropping reset_source_set_instance() and instead introduce a function
that can set all relevant parameters (source, priority and instance) in
one go.

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

watchdog: stm32_iwdg: remove left-over comment ...

The reset reason part of the code is based on the i.MX6's and duplicated
a comment from there, which isn't applicable to the STM32. Delete it.

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

watchdog: add stm32 watchdog and reset driver ...

The driver supports setting watchdog timeout, system reset
and querying reset reason. Disabling watchdog isn't possible
in hardware, thus users should either only enable it before
boot or have the poller take care of feeding it.

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

watchdog: imx: Add big endian register access support ...

Layerscape SoCs feature the same watchdog as the i.MX SoCs, but in big
endian mode. Add support for it.

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

watchdog: imx: Add register accessor functions ...

In preparation of adding big endian support in the next step.

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

Merge branch 'for-next/rpi'