Dear Patrick, In message <1567530547-14331-1-git-send-email-patrick.delau...@st.com> you wrote: > Add a new flag CONFIG_ENV_SUPPORT to compile all > the environment features in U-Boot (attributes, callbacks > and flags). It is the equivalent of the 2 existing flags
I think this is a bda name, as it is misleading. It sounds as if it is used to enable the support of environment vaiables at all, which it does not - instead it only enables / disables a few specific extended features. This must be reflected in the name. > - CONFIG_SPL_ENV_SUPPORT for SPL > - CONFIG_TPL_ENV_SUPPORT for TPL This scares me. Why are there different settings for SPL, TPL and U-Boot proper? This looks conceptually broken to me - if a system is configured to use a specific set of environment features and extensions, then the exact same settings must be use in all of SPL, TPL and U-Boot proper. I understand that it may be desirable for example to reduce the size of the SPL by omitting some environment extensions, but provide these in U-Boot proper, but this is broken and dangerous. For example, U-Boot flags are often used to enforce a certain level of security (say, by making environment variables read-only or such). The same level of handling and protection must also be maintained in SPL and TPL. So please reconsider this whole implementation, and make sure that only a single macro ise used everywhere to enable these features. Best regards, Wolfgang Denk -- 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: w...@denx.de Never ascribe to malice that which can adequately be explained by stupidity. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot