[PATCH] env: Add option to only ever append environment

[Marek Vasut]

On 6/3/20 1:32 AM, Tom Rini wrote:
> On Tue, Jun 02, 2020 at 09:06:42PM +0200, Marek Vasut wrote:
>> On 6/2/20 7:36 PM, Tom Rini wrote:
>> [...]
>>>>>>>> One will append the environment, the other will override it (if you have
>>>>>>>> multiple envs enabled).
>>>>>>>
>>>>>>> So it sounds like it wouldn't be valid to have this option differ
>>>>>>> between SPL and main U-Boot?
>>>>>>
>>>>>> Consider the case where you have default env in SPL, and multiple envs
>>>>>> in U-Boot proper.
>>>>>
>>>>> Yes, today you can end up with cases where you build something that doesn't
>>>>> work as intended (likely something around falcon boot and/or boot count
>>>>> limit in env).  Which is what I'm getting at here.  Is there some
>>>>> cases where it would make any sense to enable this option in full U-Boot
>>>>> but disable it in SPL?
>>>>
>>>> Yes, like my current use case, where I want to configure the SPL
>>>> differently than U-Boot itself. SPL doesn't even have environment
>>>> support enabled, but it might be needed later.
>>>
>>> Sorry I wasn't clear enough.  Does it make sense (when? how?) to have
>>> environment in SPL but mismatch this feature?
>>
>> If you have only one env source in SPL and multiple in U-Boot for
>> example. But this is besides the point,
> 
> Yes, so lets set that aside.
> 
>> I want to be able to configure
>> my env handling whichever I need it to without working around problems
>> like the ones below.
> 
> You're instead adding two others kinds of problems.  You're adding code
> that would make use of a symbol that doesn't exist.  You're also adding
> what seems like a non-functional runtime (we set the variable in full
> U-Boot and can't read it in SPL).  So can you confirm that having this
> enabled in full U-Boot but disabled in SPL does not result in the case
> of a mismatch in the environment, in the case of having access to more
> than just the default compiled environment?

I have the env completely disabled in SPL, so it does not.

>>>> And also, I don't want to end up in the same problem we currently have
>>>> e.g. with USB gadget, where I have to manually #ifdef CONFIG_SPL_BUILD
>>>> #undef CONFIG_ options in the board config file.
>>>
>>> Yes, don't do that, I've had to fix a few of those of late in catching
>>> converted but still in config header options.
>>
>> This is the result of not having a dedicated SPL/TPL config options though.
> 
> Then we should fix that.  But not every option is/should be listed in
> triplicate.

OK, then I can re-do this patch without the CONFIG_IS_ENABLED() and then
add another #undef into the board config.