On Fri, Jun 05, 2020 at 10:47:24PM +0200, Marek Vasut wrote:
On 6/5/20 9:07 PM, Tom Rini wrote:
On Wed, Jun 03, 2020 at 02:01:08AM +0200, Marek Vasut wrote:
In case the env storage driver marks environment as ENV_INVALID, we must reset the $ret return value to -ENOENT to let the env init code reset the environment to the default one a bit further down.
Signed-off-by: Marek Vasut marex@denx.de
env/env.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/env/env.c b/env/env.c index dcc25c030b..024d36fdbe 100644 --- a/env/env.c +++ b/env/env.c @@ -300,6 +300,9 @@ int env_init(void)
debug("%s: Environment %s init done (ret=%d)\n", __func__, drv->name, ret);
if (gd->env_valid == ENV_INVALID)ret = -ENOENT;}
if (!prio)
Is the storage driver marking the environment as invalid but not returning ENOENT valid?
Yes, some are doing that.
Why? Is that correct or incorrect? It doesn't seem like this is something that should be inconsistent from storage driver to storage driver and needs fixing.
How does all of this work in the case of multiple configured storage drivers?
If the env is invalid, then we report it as invalid.
Right. And what change, if any, does your proposed change have in this case? Thanks!