public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 06/10] env: Support multiple environments
Date: Fri, 17 Nov 2017 15:00:15 +0100	[thread overview]
Message-ID: <20171117150015.3a5c3cc7@jawa> (raw)
In-Reply-To: <20171117134105.GN9986@bill-the-cat>

On Fri, 17 Nov 2017 08:41:05 -0500
Tom Rini <trini@konsulko.com> wrote:

> On Fri, Nov 17, 2017 at 10:24:37AM +0100, Lukasz Majewski wrote:
> > Hi Maxime,
> >   
> > > Now that we have everything in place to support multiple
> > > environment, let's make sure the current code can use it.
> > > 
> > > The priority used between the various environment is the same one
> > > that was used in the code previously.
> > > 
> > > At read / init times, the highest priority environment is going
> > > to be detected, and we'll use the same one without lookup during
> > > writes. This should implement the same behaviour than we
> > > currently have.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > >  env/env.c | 75
> > > ++++++++++++++++++++++++++++++++++++++++++--------------------- 1
> > > file changed, 50 insertions(+), 25 deletions(-)
> > > 
> > > diff --git a/env/env.c b/env/env.c
> > > index 1d13220aa79b..6af9f897b0ae 100644
> > > --- a/env/env.c
> > > +++ b/env/env.c
> > > @@ -26,33 +26,58 @@ static struct env_driver
> > > *_env_driver_lookup(enum env_location loc) return NULL;
> > >  }
> > >  
> > > +static enum env_location env_locations[] = {
> > > +#ifdef CONFIG_ENV_IS_IN_EEPROM
> > > +	ENVL_EEPROM,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_FAT
> > > +	ENVL_FAT,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_FLASH
> > > +	ENVL_FLASH,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_MMC
> > > +	ENVL_MMC,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_NAND
> > > +	ENVL_NAND,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_NVRAM
> > > +	ENVL_NVRAM,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_REMOTE
> > > +	ENVL_REMOTE,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> > > +	ENVL_SPI_FLASH,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_IN_UBI
> > > +	ENVL_UBI,
> > > +#endif
> > > +#ifdef CONFIG_ENV_IS_NOWHERE
> > > +	ENVL_NOWHERE,
> > > +#endif
> > > +	ENVL_UNKNOWN,
> > > +};
> > > +
> > > +static enum env_location env_load_location;
> > > +
> > >  static enum env_location env_get_location(enum env_operation op,
> > > int prio) {
> > > -	if (prio >= 1)
> > > -		return ENVL_UNKNOWN;
> > > -
> > > -	if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
> > > -		return ENVL_EEPROM;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
> > > -		return ENVL_FAT;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
> > > -		return ENVL_FLASH;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
> > > -		return ENVL_MMC;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_NAND)
> > > -		return ENVL_NAND;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_NVRAM)
> > > -		return ENVL_NVRAM;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_REMOTE)
> > > -		return ENVL_REMOTE;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)
> > > -		return ENVL_SPI_FLASH;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_IN_UBI)
> > > -		return ENVL_UBI;
> > > -	else if IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
> > > -		return ENVL_NOWHERE;
> > > -	else
> > > -		return ENVL_UNKNOWN;
> > > +	switch (op) {
> > > +	case ENVO_GET_CHAR:
> > > +	case ENVO_INIT:
> > > +	case ENVO_LOAD:
> > > +		if (prio >= ARRAY_SIZE(env_locations))
> > > +			return -ENODEV;
> > > +
> > > +		return env_load_location = env_locations[prio];
> > > +
> > > +	case ENVO_SAVE:
> > > +		return env_load_location;
> > > +	}
> > > +
> > > +	return ENVL_UNKNOWN;
> > >  }
> > >  
> > >  static struct env_driver *env_driver_lookup(enum env_operation
> > > op, int prio)  
> > 
> > I'm just wondering...
> > 
> > Do you think that it may be helpful to have a way to force
> > particular environment to be used (despite of the priority)?  
> 
> That's one of the hard parts of this, yes.  I think I had suggested
> before that we handle that in a follow up series?
> 

I don't want to say that this must be done now. I just can imagine that
we may need such feature in some point.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171117/ac8a0903/attachment.sig>

  reply	other threads:[~2017-11-17 14:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  9:22 [U-Boot] [RFC PATCH 00/10] env: Multiple env support and env transition for sunxi Maxime Ripard
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 01/10] cmd: nvedit: Get rid of the env lookup Maxime Ripard
2017-11-17  9:12   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 02/10] env: Make env_driver_lookup_default private Maxime Ripard
2017-11-17  9:13   ` Lukasz Majewski
2017-11-20  9:53   ` Andre Przywara
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 03/10] env: Rename env_driver_lookup_default and env_get_default_location Maxime Ripard
2017-11-17  9:14   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 04/10] env: Pass additional parameters to the env lookup function Maxime Ripard
2017-11-17  9:19   ` Lukasz Majewski
2017-11-24  9:20   ` Quentin Schulz
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 05/10] env: Make the env save message a bit more explicit Maxime Ripard
2017-11-17  9:20   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 06/10] env: Support multiple environments Maxime Ripard
2017-11-17  9:24   ` Lukasz Majewski
2017-11-17 13:41     ` Tom Rini
2017-11-17 14:00       ` Lukasz Majewski [this message]
2017-11-17 14:19         ` Maxime Ripard
2017-11-17 14:40           ` Lukasz Majewski
2017-11-17 17:07             ` Maxime Ripard
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 07/10] env: Allow to build multiple environments in Kconfig Maxime Ripard
2017-11-17  9:25   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 08/10] env: Mark env_get_location as weak Maxime Ripard
2017-11-17  9:26   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 09/10] sunxi: Transition from the MMC to a FAT-based environment Maxime Ripard
2017-11-17  9:27   ` Lukasz Majewski
2017-11-16  9:22 ` [U-Boot] [RFC PATCH 10/10] env: sunxi: Enable FAT-based environment support by default Maxime Ripard
2017-11-17  9:27   ` Lukasz Majewski

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=20171117150015.3a5c3cc7@jawa \
    --to=lukma@denx.de \
    --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