On Fri, Mar 27, 2020 at 12:02:00AM +0100, Rasmus Villemoes wrote: > 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.villem...@prevas.dk>
Applied to u-boot/master, thanks! -- Tom
signature.asc
Description: PGP signature
