Now that SPL means SPL (only) and is not defined for other phases,
update kconfig rules.

This is done in one patch since otherwise many Binman tests fail.

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

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

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

Add support for VPL, a new phase of U-Boot. This runs after TPL. It is
responsible for selecting which SPL binary to run, based on a
verified-boot process.

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

At present if an optional Kconfig value needs to be used it must be
bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE
	bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR
	hex "Address of the wibble"
	depends on WIBBLE

then the following code must be used:

 #ifdef CONFIG_WIBBLE
 static void handle_wibble(void)
 {
 	int val = CONFIG_WIBBLE_ADDR;

	...
 }
 #endif

 static void init_machine()
 {
 ...
 #ifdef CONFIG_WIBBLE
	handle_wibble();
 #endif
 }

Add a new IF_ENABLED_INT() to help with this. So now it is possible to
write, without #ifdefs:

 static void handle_wibble(void)
 {
        int val = IF_ENABLED_INT(CONFIG_WIBBLE, CONFIG_WIBBLE_ADDR);

	...
 }

 static void init_machine()
 {
 ...
 if (IS_ENABLED(CONFIG_WIBBLE))
	handle_wibble();
 }

The value will be CONFIG_WIBBLE_ADDR if CONFIG_WIBBLE is defined and will
produce a build error if not.. This allows us to reduce the use of #ifdef
in the code, ensuring that the compiler still checks the code even if it
is not ultimately used for a particular build.

Add a CONFIG_IF_ENABLED_INT() version as well.

If an attempt is made to use a value that does not exist (i.e. when the
conditional is not enabled), an error about a non-existing function is
generated, e.g.:

common/bloblist.c:447: undefined reference to `invalid_use_of_IF_ENABLED_INT'

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

The config_enabled() macro currently uses 0 as the default value. Update
it to allow any value, so we can pass it something else, such as a
non-existent function, to produce a build error if it is not defined.

Also tidy up the code style for IS_ENABLED() and drop the unnecessary
brackets (the value is a simple 0 or 1).

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

At present we must separately test for the host build for many options,
since we force them to be enabled. For example, CONFIG_FIT is always
enabled in the host tools, even if CONFIG_FIT is not enabled by the
board itself.

It would be more convenient if we could use, for example,
CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
host. Add support for this.

With this and the tools_build() function, we should be able to remove all
the #ifdefs currently needed in code that is build by tools and targets.

This will be even nicer when we move to using CONFIG(xxx) everywhere,
since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go away.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> # b4f73886
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of

  CONFIG_IS_ENABLED(FOO)

expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form

  CONFIG_IS_ENABLED(FOO, (something))

which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines

  #if CONFIG_IS_ENABLED(FOO)
  something
  #endif

The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.

A third variant is also introduced,

  CONFIG_IS_ENABLED(FOO, (xxx), (yyy))

which corresponds to

  #if CONFIG_IS_ENABLED(FOO)
  xxx
  #else
  yyy
  #endif

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.

While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.

This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>

This patch adds some commit info for CONFIG_IS_ENABLED(FOO) when used in
TPL context.

Signed-off-by: Lukasz Majewski <lukma@denx.de>