From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2 3/9] env: correctly handle result in env_init
Date: Thu, 18 Jun 2020 15:15:30 -0400 [thread overview]
Message-ID: <20200618191530.GU27801@bill-the-cat> (raw)
In-Reply-To: <20200616074048.7898-4-patrick.delaunay@st.com>
On Tue, Jun 16, 2020 at 09:40:42AM +0200, Patrick Delaunay wrote:
> Don't return error with ret=-ENOENT when the optional ops drv->init
> is absent but only if env_driver_lookup doesn't found driver.
>
> This patch correct an issue for the code
> if (!env_init())
> env_load()
> When only ext4 is supported (CONFIG_ENV_IS_IN_EXT4),
> as the backend env/ext4.c doesn't define an ops .init
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
> ---
>
> (no changes since v1)
>
> env/env.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/env/env.c b/env/env.c
> index dcc25c030b..819c88f729 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -295,7 +295,10 @@ int env_init(void)
> int prio;
>
> for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
> - if (!drv->init || !(ret = drv->init()))
> + ret = 0;
> + if (drv->init)
> + ret = drv->init();
> + if (!ret)
> env_set_inited(drv->location);
>
> debug("%s: Environment %s init done (ret=%d)\n", __func__,
I'm adding in Marek here because this reminds me of similar questions /
concerns I had looking in to his series. At root, I think we're not
being consistent in each of our env backing implementations about where
flags such as ENV_VALID are set, and return values / checks of
functions.
Just outside of the start of the patch context here, we set ret to
-ENOENT and just past this, if still -ENOENT we say ENV_VALID and point
at the default environment.
But, I don't follow the patch commit message here. If we don't have
drv->init we call env_set_inited(drv->location) but we won't have change
ret to 0, which means that later on down the function we go back to
default environment.
So isn't this a problem in most environment cases then? Thanks!
--
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/20200618/e4e8eac0/attachment.sig>
next prev parent reply other threads:[~2020-06-18 19:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 7:40 [PATCH v2 0/9] env: ext4: corrections and add test for env in ext4 Patrick Delaunay
2020-06-16 7:40 ` [PATCH v2 1/9] env: add absolute path at CONFIG_ENV_EXT4_FILE Patrick Delaunay
2020-06-18 19:25 ` Tom Rini
2020-06-16 7:40 ` [PATCH v2 2/9] env: ext4: set gd->env_valid Patrick Delaunay
2020-06-18 19:25 ` Tom Rini
2020-06-16 7:40 ` [PATCH v2 3/9] env: correctly handle result in env_init Patrick Delaunay
2020-06-18 19:15 ` Tom Rini [this message]
2020-06-19 14:14 ` Patrick DELAUNAY
2020-06-19 18:05 ` Tom Rini
2020-06-23 13:13 ` Patrick DELAUNAY
2020-06-23 15:16 ` Tom Rini
2020-06-24 11:19 ` Patrick DELAUNAY
2020-06-24 18:07 ` Tom Rini
2020-06-16 7:40 ` [PATCH v2 4/9] sandbox: activate env in ext4 support Patrick Delaunay
2020-06-16 7:40 ` [PATCH v2 5/9] sandbox: support the change of env location Patrick Delaunay
2020-06-17 3:12 ` Simon Glass
2020-06-18 19:17 ` Tom Rini
2020-06-19 14:40 ` Patrick DELAUNAY
2020-06-19 18:07 ` Tom Rini
2020-06-16 7:40 ` [PATCH v2 6/9] test: environment in ext4 Patrick Delaunay
2020-06-22 18:57 ` Stephen Warren
2020-06-23 18:00 ` Patrick DELAUNAY
2020-06-16 7:40 ` [PATCH v2 7/9] env: ext4: introduce new function env_ext4_save_buffer Patrick Delaunay
2020-06-16 7:40 ` [PATCH v2 8/9] env: ext4: add support of command env erase Patrick Delaunay
2020-06-16 7:40 ` [PATCH v2 9/9] test: sandbox: add test for erase command Patrick Delaunay
2020-06-17 3:12 ` Simon Glass
2020-06-22 18:58 ` Stephen Warren
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=20200618191530.GU27801@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox