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 <tr...@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.hei...@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 <p...@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