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

[Wolfgang Denk <wd@denx.de>]

Dear Rasmus,

In message <8ff3b8ad-8c4e-fe99-69c8-7c174e997a49@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.

> I certainly agree the current naming isn't very accurate, but the
> ability to choose CONFIG_ENV_IS_NOWHERE along with some "real" storage
> option is quite useful. We use it so that we can use the exact same
> U-Boot binary for both development and production, just different .dtbs;
> there's a board-specific env_get_location() which reads a DT property to
> decide whether to return ENVL_SPI_FLASH or ENVL_NOWHERE. Whether there
> actually needs to be a stub nowhere.c driver for that or one could just
> return ENVL_UNKNOWN I don't know.

If it makes sense do have a nulldev, then it should be added as a
CONFIG_ENV_IS_ option.  This is something fundamental different from
NOWHERE.

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A metaphor is like a simile.