The ofnode_find_subnode() function currently processes things two
different ways, so the treatment of unit addresses differs depending on
whether OF_LIVE is enabled or not.

Add a new version which uses the ofnode API and add a test to check that
unit addresses can be matched correctly. Leave the old function in place
for the !OF_LIVE case, to avoid a code-size increase, e.g. on
firefly-rk3288

Signed-off-by: Simon Glass <sjg@chromium.org>

When a unit-address is provided, use it to match against the node
name.

Since this increases code size, put it into a separate function.

Signed-off-by: Simon Glass <sjg@chromium.org>

Update ofnode_add_subnode() and ofnode_add_prop() to return a suitable
error when space is exhausted in the FDT. This makes it easier to see
what is going wrong.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

At some point it would be nice to have the ofnode API automatically
expand the tree as required, to accommodate new nodes. For now, expand
the default size so that UPL can be supported.

Signed-off-by: Simon Glass <sjg@chromium.org>

Implement ofnode_options phandle helper to get an ofnode from a phandle
option in /options/u-boot.

This helper can be useful since new DT yaml usually require to link a
phandle of a node instead of referencing it by name or other indirect
way.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Implement ofnode/tree_parse_phandle() helper as an equivalent of
of_parse_phandle to handle simple single value phandle.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Implement oftree variant of parse_phandle OPs.

There is currently a very hidden and laten BUG with parse_phandle OPs
that doesn't permit the support of multiple DTS in a system. One usage
example if sandbox with the usage of other.dts

The BUG is only present on live scenario where of_... OPs are used and
it's not present when fdt... OPs are used.

This is caused by an assumption made in __of_parse_phandle_with_args,
with the of_find_node_by_phandle call that pass the first arg as NULL.

This makes of_find_node_by_phandle use the default root node of the
system and doesn't permit the usage of alternative tree. This is correct
for normal system and also for the linux kernel where it's assumed a
single device tree.

It's problematic if other device tree needs to be used.

To fix this, introduce __of_root_parse_phandle_with_args to define a
root device tree for of_find_node_by_phandle.

Introduce all the variant OPs for this and in ofnode, the oftree OPs
following how it's done for other OPs with similar task.

For FDT scenario, ofnode_from_fdtdec_phandle_args is reworked to accept
a new variable, node and noffset_to_ofnode is used instead of
offset_to_ofnode. This is required to support multiple FDB blob to
calculate the correct of_offset of the ofnode.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

People complained that enabling (SPL_)DM_WARN was now totally unusable
due to the amount of messages printed on the console.

Let's downgrade the log level of some messages that are clearly not on
the error path.

Note that there's one pr_debug in there, because it is followed by
pr_cont so it made sense to reuse the same family of functions.

Reported-by: Alexander Dahl <ada@thorsis.com>
Fixes: 6afdb1585112 ("dm: core: migrate debug() messages to use dm_warn")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Simon Glass <sjg@chromium.org> says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>