[PATCH] env: env_sf: don't set .init op if not needed

[Rasmus Villemoes]

On 05/11/2020 17.40, Wolfgang Denk wrote:
> Dear Rasmus,
> 
> In message <8ff3b8ad-8c4e-fe99-69c8-7c174e997a49 at prevas.dk> you wrote:
>>
>>>> Not in a none standard way! Instead you can define more than one
>>>> environment storage devices and load them in a board specific order
>>>> (defined thorugh board specfif function env_get_location())
>>>
>>> Yes, agreed.  But this logically impossible if there is no storage
>>> at all, which is what CONFIG_ENV_IS_NOWHERE says.
>>
>> Then should all the current config options CONFIG_ENV_IS_ be renamed to
>> CONFIG_ENV_MAY_BE_? Because that's really what they mean.
> 
> This is not correct.
> 
> The CONFIG_ENV_IS_FOO means: if you use "env save", then U-Boot will
> write the config to external storage using the FOO storage device.

Wolfgang, you're wrong. What you're saying was once true, when the
location was a "choice" in Kconfig, but it hasn't been that since
fb69464eae. Nowadays one can select multiple possible backends, and only
one of them will be used when doing "env save".

Later (208bd2b8), _NOWHERE was made non-mutually-exclusive with the real
storage targets.

> If you define CONFIG_ENV_IS_NOWHERE, I would for example expect that
> all "env save" related code is omitted as we will never need it.

I haven't checked, but that functionality does seem to exist - not
depending on whether CONFIG_ENV_IS_NOWHERE is not selected, but whether
any of the CONFIG_ENV_IS_<somehere> is. See the ENV_IS_IN_DEVICE logic
in cmd/nvedit.c. So if you select CONFIG_ENV_IS_NOWHERE and not any of
the others, I think the build works as you'd expect.

Rasmus