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 <ma...@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! -- Tom
signature.asc
Description: PGP signature
