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 <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.
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.
