[PATCH 3/6] env: Fix invalid env handling in env_init()

[Tom Rini <trini@konsulko.com>]

On Sat, Jun 06, 2020 at 04:54:52PM +0200, Marek Vasut wrote:
> On 6/5/20 11:11 PM, Tom Rini wrote:
> > 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.
> 
> The default env driver is doing it, whether it's a workaround or correct
> behavior, I really don't know. Maybe Joe does ?
> 
> >>> 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!
> 
> Before this patch, that check was missing and the result was random,
> depending on which env order you had.

So have you changed the behavior of multiple environments then?  Today
it's indeed link order based, which is not optimal but used.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200606/4c53cc6f/attachment.sig>