[PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime

[Andre Heider <a.heider@gmail.com>]

On 02/02/2021 17:32, Stefan Roese wrote:
> On 02.02.21 17:13, Andre Heider wrote:
>> On 02/02/2021 16:09, Stefan Roese wrote:
>>> Hi Pali,
>>> Hi Andre,
>>>
>>> On 12.01.21 10:24, Pali Roh?r wrote:
>>>> Hello!
>>>>
>>>> On Tuesday 12 January 2021 09:18:44 Andre Heider wrote:
>>>>> Hi Pali,
>>>>>
>>>>> On 11/01/2021 11:51, Pali Roh?r wrote:
>>>>>> Hello Stefan and Andre!
>>>>>>
>>>>>> Could you please look at this patch series and tell me what do you 
>>>>>> think
>>>>>> about it? If it is fine or needs to take different approach?
>>>>>
>>>>> I like the idea very much, and I bet there're quite some boards 
>>>>> which could
>>>>> make good use of "immutable envvars".
>>>>>
>>>>> The obvious review point is the filler thing and its dependency on
>>>>> DEFAULT_ENV_IS_RW, which probably won't win a beauty contest :) 
>>>>> Maybe a
>>>>> nicer integration would help in getting it merged?
>>>>>
>>>>> I don't think it would take too much effort, first thing that comes 
>>>>> to mind:
>>>>> - board provides list of immutable vars
>>>>> - env_set_default() backs up these vars
>>>>> - env_set_default() imports default_environment
>>>>> - env_set_default() imports backup on top
>>>>>
>>>>> The last step should be easy, see env_set_default_vars().
>>>>
>>>> This could probably work for $ethNaddr variables.
>>>>
>>>> But there is still an issue how to handle $fdtfile. There is basically
>>>> default value for this variable, but value itself cannot be determined
>>>> at compile time, only at runtime. And for it variable flags do not 
>>>> help,
>>>> we just need an mechanism how to set default variable values not 
>>>> only at
>>>> compile time but also runtime.
>>>>
>>>> That is why I chosen for now solution with modifying
>>>> default_environment[] array as it solve issue for both $fdtfile and
>>>> $ethNaddr variables.
>>>
>>> So what is the outcome of this discussion? Andre, do you see any
>>> hindering points in this patch series, apart from it not winning a
>>> "beauty contest"? ;)
>>
>> Hehe, nope, only aesthetic concerns, no hinderung points to block this 
>> going in.
> 
> I see. Then if appropriate, please send any matching tag(s) to these
> patches.

I didn't test it, so this set is at least:
Acked-by: Andre Heider <a.heider@gmail.com>

Thanks,
Andre