[PATCH] defconfig: espressobin: enable NET_RANDOM_ETHADDR

[Dennis Gilmore]

I agree with Tom here, I have a few different systems that use this
feature, it is useful. I think most if not all of the systems I have
using it have Marvell SoC's

Dennis

On Fri, Sep 11, 2020 at 12:11 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Sep 11, 2020 at 06:47:02PM +0200, Andre Heider wrote:
> > On 11/09/2020 18:22, Marek Behún wrote:
> > > On Fri, 11 Sep 2020 17:52:26 +0200
> > > Andre Heider <a.heider at gmail.com> wrote:
> > >
> > > > 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 at 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.
> > > >
> > >
> > > I understand Pali's concerns, though.
> > >
> > > The thing is that if we enable CONFIG_NET_RANDOM_ETHADDR by default,
> > > many users that have managed to wipe their env won't care about that
> > > they are using randomly generated MAC address and won't solve the issue,
> > > which is again the spirit of correctly configure networks.
> > >
> > > If we do not enable CONFIG_NET_RANDOM_ETHADDR, the worst that can
> > > happen is that the device won't boot from network. This will force the
> > > users to solve the issue, which is not that hard
> > >    setenv ethaddr aa:bb:cc:dd:ee:ff (address from the sticker)
> > >    saveenv
> > > If the users boots from SD/eMMC/SATA/USB, Linux won't have problem with
> > > network, since it will generate random MAC address anyway.
> >
> > Good point, so let's assume the user doesn't have a mac stored.
> >
> > Without CONFIG_NET_RANDOM_ETHADDR:
> > * u-boot refuses to do anything network related
> > * Linux generates a random mac, network works
> >
> > With CONFIG_NET_RANDOM_ETHADDR:
> > * u-boot generates a random mac, network works
> > * Linux uses the same random mac, passed on from u-boot throught the
> > device-tree, network works
> >
> > It's still random, but at least it's consistent ;)
>
> It's also only used when we cannot find the MAC.  At the end of the day,
> the final decision here is Konstantin's (as the listed maintainer).  I
> personally think enabling the option is good given the apparent number
> of ways the real MAC will have been lost from SW, but if the maintainer
> wants to instead opt for a verbose failure message, that's fine too.
>
> --
> Tom