mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-12-01 17:10:11 +00:00
6d3524c2ad
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> |
||
|---|---|---|
| .. | ||
| attr.c | ||
| callback.c | ||
| common.c | ||
| eeprom.c | ||
| embedded.c | ||
| env.c | ||
| ext4.c | ||
| fat.c | ||
| flags.c | ||
| flash.c | ||
| Kconfig | ||
| Makefile | ||
| mmc.c | ||
| nand.c | ||
| nowhere.c | ||
| nvram.c | ||
| onenand.c | ||
| remote.c | ||
| sata.c | ||
| sf.c | ||
| ubi.c | ||