[PATCH v2 2/2] env/sf.c: honour CONFIG_SPL_SAVEENV

[Tom Rini]

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.villemoes at prevas.dk>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200508/966d2d32/attachment.sig>