From 6d3524c2ad9f5b38cf759566c78e4761aeab4c97 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Fri, 27 Mar 2020 00:02:00 +0100 Subject: [PATCH] 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 " ? env_sf_save : NULL" construction instead of a macro that just eats its argument and expands to NULL. That way, if is false, env_sf_save gets eliminated as dead code, but the compiler still sees the reference to it. For , 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 --- env/sf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/sf.c b/env/sf.c index 22b70ad..64c57f2 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 -- 2.7.4