[PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

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

Hi Marek,

On 11/09/2020 13:55, Marek Beh?n wrote:
> On Wed, 9 Sep 2020 00:38:31 +0200 Pali Roh?r <pali@kernel.org> wrote:
>> On Tuesday 08 September 2020 08:52:56 Tom Rini wrote:
>>> Note that when CONFIG_NET_RANDOM_ETHADDR is set, we only use a
>>> random MAC address when we haven't found one either on the hardware
>>> or environment.
>>
>> I know.
>>
>>> It also prints a warning that you are using a random MAC,
>>> so if it's documented on how to recover the real MAC a user should
>>> see that warning and fix it.
>>
>> In case you did backup of MAC address or you have MAC address printed
>> on sticker, you can restore it. If you loaded distribution U-Boot
>> which erase MAC address and you have not did any backup, then your
>> MAC address is forever lost.
> 
> On Turris MOX we write the MAC address into OTP of the SOC during
> manufacturing.
> 
> It is possible to write code that burns the MAC address into OTP, I
> consider this a better option than enabling random MAC address.
> 
> Maybe we can enable random MAC address, and if MAC address is not found
> in environment nor OTP, issue a warning, something like
>    "WARNING: MAC address lost, please burn the MAC address of your device
>              to OTP with command xyz"
> 
> What do you think?

if there's a mac stored in otp during manufacturing, that's of course 
the best solution. There's no need for CONFIG_NET_RANDOM_ETHADDR then. 
But globalscale does not do that.

Doing it afterwards, so u-boot claiming some otp space for itself, and 
instructing the user how to write to it sounds too dangerous/error-prone.

For me CONFIG_NET_RANDOM_ETHADDR is a knob that should be enabled if 
there's no mac address stored in a sane way (where saving it just to an 
u-boot env during manufacturing doesn't count as sane, especially if the 
vendor moves the spi env offset around in a firmware update).

So I think CONFIG_NET_RANDOM_ETHADDR is enough.

But it would be nice if e.g. a board could set specific env vars as 
indestructible/unwipeable/precious/whatever, which instructs `env 
default -a` to keep those (which is common after updating the 
bootloader). Maybe that's an idea worth pursuing?

Thanks,
Andre