[PATCH RFC] cmd: fix net list command

Wolfgang Denk wd at denx.de
Tue Nov 16 15:51:39 CET 2021

Dear Tom,

In message <20211116141030.GC24579 at bill-the-cat> you wrote:
> One thing I'm not totally sure on yet is, looking at the README I see:
> "If Ethernet drivers implement the 'write_hwaddr' function, valid MAC
> addresses will be programmed into hardware as part of the initialization
> process.  This may be skipped by setting the appropriate 'ethmacskip'
> environment variable.  The naming convention is as follows: "ethmacskip"
> (=>eth0), "eth1macskip" (=>eth1) etc."

I have to admit that until now I was not even aware of these

> As I'm sure that predates device trees being used to the extent they are
> now, should 'ethmacskip' be involved in the "fixup the device tree"
> logic, and appropriate rST / Kconfig help text updated?  My first
> reaction is that in spirit, this is how to solve Michael's use case and
> README / doc/README.enetaddr do not specify when/why the "also fixup the
> device tree if it exists" is done.

Apparently this logic was added more than 10 years ago in commit
ecee9324d "Program net device MAC addresses after initializing".

I think it does not change anything to the logic that Linux uses the
MAC address passed by U-Boot. Whether U-Boot also writes some MAC
address to the device's persistent storage is an independent act.
If there already was an addressed stored there befoire it would not
have been read by Linux, so the same should happen here.

[Here it is even less problematic as U-Boot has the very same MAC
address in it's environment.]

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_

More information about the U-Boot mailing list