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

[Stefan Roese]

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.

Thanks,
Stefan