param: add dev_add_param_tristate(_ro) helpers ...

This is can be considered an extension to the dev_add_param_bool
interfaces with a third value that's "unknown".
This can be used for cases, where barebox can flip a bit somewhere,
but it has no way of knowing what the initial state of the bit was,
e.g. turn on/off the watchdog, but no watchdog status.
Turn on/off a co-processor, but no co-processor online status.
And so on. Not providing a way to customize the "unknown" string
is a deliberate choice, so future device parameters follow the same
naming scheme.

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: 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>

ARM: mmu-early: On i.MX6 with HAB map ROM is mapped without XN ...

On i.MX6 with HAB enabled we call into the ROM later in
imx6_hab_get_status(). This only works when the XN bit is not set for
this area, so remap the first MiB as cached which doesn't have the XN
bit set.

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

Merge branch 'for-next/zynqmp'

Merge branch 'for-next/watchdog'

Merge branch 'for-next/stm32'

Merge branch 'for-next/socfpga'

Merge branch 'for-next/misc'

Merge branch 'for-next/mips'

Merge branch 'for-next/imx'

Merge branch 'for-next/ext4'

Merge branch 'for-next/efi'

Merge branch 'for-next/dts'

dts: update to v5.4-rc6 ...

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

Release v2019.11.0 ...

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

ARM: dts: stm32mp: report psci v0.2 at least ...

ARM TF-A reports compatibility with PSCI v1.1 since v1.5. Upstream
ARM TF-A support for STM32MP was introduced with v1.6.
It's thus safe to assume that the STM32MP barebox will never have to
interact with a secure monitor implementing PSCI v0.1.

Overwrite the psci device tree compatible to specify v0.2. This is the
first version that implements PSCI_VERSION, which allows the barebox
psci client driver selected in this commit to query the actual PSCI
version and fix it up into the device tree.

This fixes an issue where resetting via PSCI fails in Linux because the
upstream device tree compatible:

  reboot: Restarting system
  Reboot failed -- System halted

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

ARM: stm32mp: select ARM_USE_COMPRESSED_DTB for the whole arch ...

We'll probably be using compressed DTBs for all new boards as well, thus
move the ARM_USE_COMPRESSED_DTB, so it's always selected for STM32MP.

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

ARM: psci: implement PSCI client driver ...

System reset on the STM32MP may be done via PSCI when running TF-A
as first-stage boot loader. Provide a PSCI driver to simplify using it:

- A psci_invoke function is exported, so other code can use it
- A fixup for the PSCI device tree node is registered
- A reset and poweroff handler via PSCI is registered for PSCI >= v0.2

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

ARM: psci: wire in smc command help ...

The smc command has a help defined, but unused. Wire it in, so
help smc and smc -invalidoption work as expected.

While at it, remove the unimplemented -z option. It's unneeded,
because -c turns off the CPU after starting it again already.
Also it seems it's not implementable without interprocessor communication,
which is probably overkill here.

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

ARM: psci: use CONFIG_ARM_PSCI_DEBUG for smc command ...

There's already an option to use when debugging PSCI. Instead of
requiring users to #define DEBUG 1 as well, have the smc command be
usable when CONFIG_ARM_PSCI_DEBUG, not DEBUG is defined.

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

ARM: psci: translate PSCI error codes in smc command ...

For more usability, translate CPU_ON error codes into the error
descriptions found in the PSCI Platform Design Document[1].

[1]: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

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

MIPS: loongsonl: pull headers from linux kernel ...

Signed-off-by: Du Huanpeng <u74147@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ARM: stm32mp: enable STPMIC1 MFD and cell drivers ...

The STPMIC1 is the ST Microelectronics PMIC designed for use with
STM32MP. Enable it and its cell drivers by default in the defconfig.

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

ARM: dts: stm32mp157a-dk1: remove unnecessary sram node ...

This node has so far been unused and is a remnant from when the stm32mp
device drivers weren't completely upstream yet. Drop the node.

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

regulator: add driver for stpmic1-regulators ...

This commit imports the Linux v5.3 state of the driver. This allows us
to regulate at least the v3v3 voltage rail used by the DK1 and DK2
Ethernet PHY and SD-Card. Eventually, this driver should be used by the
USB host driver to supply the vbus voltage as well.

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

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>