All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH V2 4/7] env: Fix invalid env handling in env_init()
Date: Fri, 24 Jul 2020 10:56:55 -0400	[thread overview]
Message-ID: <20200724145655.GN6227@bill-the-cat> (raw)
In-Reply-To: <20200707185139.2225-4-marex@denx.de>

On Tue, Jul 07, 2020 at 08:51:36PM +0200, Marek Vasut wrote:

> This fixes the case where there are multiple environment drivers, one of
> them is the default environment one, and it is followed by an environment
> driver which does not implement .init() callback. The default environment
> driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
> callback implementation, which is valid behavior for default environment.
> 
> Since the subsequent environment driver does not implement .init(), it
> also does not modify the $ret variable in the loop. Therefore, the loop
> is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
> code further down in env_init() will not reset the environment to the
> default one, which is incorrect.
> 
> This patch sets the $ret variable back to -ENOENT in case the env_valid
> is set to ENV_INVALID by an environment driver, so that the environment
> would be correctly reset back to default one, unless a subsequent driver
> loads a valid environment.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> V2: Reword commit message
> ---
>  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)

So, I am not sure about this change.  Given the whole thread that ends
in https://lists.denx.de/pipermail/u-boot/2020-June/417433.html this
particular part of the function is being too clever.  I think it's
intentionally not doing what you're adding right here for some use
cases.  I think that to cleanly achieve the goals of your series we need
to stop letting drv->init be optional so that we then stop doing the
particular we're doing with "ENOENT means runs this common code path for
many envs".  We may also need to make sure the link order in
env/Makefile has nowhere first in all cases, rather than just most cases
like it does now, with a big comment on why.

-- 
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/20200724/3e3cfdfd/attachment.sig>

  reply	other threads:[~2020-07-24 14:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-07 18:51 [PATCH V2 1/7] env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set Marek Vasut
2020-07-07 18:51 ` [PATCH V2 2/7] env: Add H_DEFAULT flag Marek Vasut
2020-07-24 14:56   ` Tom Rini
2020-07-31 21:40   ` Tom Rini
2020-07-07 18:51 ` [PATCH V2 3/7] env: Discern environment coming from external storage Marek Vasut
2020-07-24 14:56   ` Tom Rini
2020-07-31 21:40   ` Tom Rini
2020-07-07 18:51 ` [PATCH V2 4/7] env: Fix invalid env handling in env_init() Marek Vasut
2020-07-24 14:56   ` Tom Rini [this message]
2020-07-28  7:28     ` Marek Vasut
2020-07-28 12:39       ` Tom Rini
2020-07-28 13:15         ` Marek Vasut
2020-07-07 18:51 ` [PATCH V2 5/7] env: nowhere: Implement .load callback Marek Vasut
2020-07-24 14:56   ` Tom Rini
2020-07-31 21:39   ` Tom Rini
2020-07-07 18:51 ` [PATCH V2 6/7] env: Add option to only ever append environment Marek Vasut
2020-07-24 14:56   ` Tom Rini
2020-07-31 21:40   ` Tom Rini
2020-07-07 18:51 ` [PATCH V2 7/7] env: Add support for explicit write access list Marek Vasut
2020-07-24 14:56   ` Tom Rini
2020-07-31 21:40   ` Tom Rini
2020-07-24 14:56 ` [PATCH V2 1/7] env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set Tom Rini
2020-07-31 21:40 ` Tom Rini
2020-10-23  8:58   ` Simon Goldschmidt
2020-10-23  9:52     ` Marek Vasut
2020-10-23 10:04       ` Simon Goldschmidt
2020-08-26 14:29 ` Alex Kiernan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200724145655.GN6227@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.