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.delau...@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
signature.asc
Description: PGP signature