env/sf.c: honour CONFIG_SPL_SAVEENV

Deciding whether to compile the env_sf_save() function based solely on
CONFIG_SPL_BUILD is wrong: For U-Boot proper, it leads to a build
warning in case CONFIG_CMD_SAVEENV=n (because the initialization of
the .save member is guarded by CONFIG_CMD_SAVEENV, while the
env_sf_save() function is built if !CONFIG_SPL_BUILD - and even
without the CONFIG_CMD_SAVEENV guard, the env_save_ptr() macro would
just expand to NULL, with no reference to env_sf_save visible to the
compiler). And for SPL, when one selects CONFIG_SPL_SAVEENV, one
obviously expects to actually be able to save the environment.

The compiler warning can be fixed by using a "<something> ?
env_sf_save : NULL" construction instead of a macro that just eats its
argument and expands to NULL. That way, if <something> is false,
env_sf_save gets eliminated as dead code, but the compiler still sees
the reference to it.

For <something>, we can use CONFIG_IS_ENABLED(SAVEENV), which is true
precisely:

- For U-Boot proper, when CONFIG_CMD_SAVEENV is set (because
  CONFIG_SAVEENV is a hidden config symbol that gets set if and only
  if CONFIG_CMD_SAVEENV is set).
- For SPL, when CONFIG_SPL_SAVEENV is set.

As a bonus, this also removes quite a few preprocessor conditionals.

This has been run-time tested on a mpc8309-derived board to verify
that saving the environment does indeed work in SPL with these patches
applied.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

1 files changed, 1 insertions, 1 deletions

diff --git a/env/sf.c b/env/sf.c
index 22b70ad319..64c57f2cdf 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -305,7 +305,7 @@ U_BOOT_ENV_LOCATION(sf) = {
 	.location	= ENVL_SPI_FLASH,
 	ENV_NAME("SPI Flash")
 	.load		= env_sf_load,
-	.save		= ENV_SAVE_PTR(env_sf_save),
+	.save		= CONFIG_IS_ENABLED(SAVEENV) ? ENV_SAVE_PTR(env_sf_save) : NULL,
 #if defined(INITENV) && (CONFIG_ENV_ADDR != 0x0)
 	.init		= env_sf_init,
 #endif