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

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

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.

Thanks,
Andre