[PATCH 10/17] bootwrapper: Add dt_set_mac_addresses().

Segher Boessenkool segher at kernel.crashing.org
Thu Mar 22 08:54:19 EST 2007

>>> If the property exists in the device tree, then it should be used, 
>>> no?  Whether or not it exists is not for the driver to decide.
>> The property doesn't describe anything about the device;
>> it merely tells you something about what the firmware did
>> during booting.
> Ah, I see your point.  But how else can the bootloader tell the kernel 
> what MAC address to use?

It should use "local-mac-address".  Quoting:

“local-mac-address” S
Standard property name to specify preassigned network address.
prop-encoded-array: Array of six bytes encoded with encode-bytes.
Specifies the 48-bit IEEE 802.3-style Media Access Control (MAC)
(as specified in ISO/IEC 8802-3 : 1993 [B3]) address assigned to
the device represented by the package, of device type “network”,
containing this property. The absence of this property indicates
that the device does not have a permanently assigned MAC address.

>> Just everything everywhere that mentions "mac-address" should be
>> completely and utterly eradicated :-)
> Are you saying that Linux should not acknowledge the existence of the 
> mac-address property, even though it's part of the OF spec?

Oh it can acknowledge its existence, it just has no business
using its contents.

>> And sure I understand you have to change one component at a
>> time -- seems to me uboot is the first step to fix?
> Depends on what you mean by a fix.  Although I understand your point 
> that the MAC address doesn't really belong in the device tree, I don't 
> see any better place for it.  So for now, I'm going on the assumption 
> that mac-address and local-mac-address are valid properties, so it's 
> just a question on *how* they should be supported.

Just use "local-mac-address", ignore "mac-address" completely,
be happy, end of world hunger.  Or something like that.

> In that context, the kernel has been updated already, and some of 
> U-Boot has also.  Well, I'm ignoring some of the more obscure IBM 
> systems, because I don't know anything about them.  All that's left is 
> 85xx, 86xx, and 5xxx, and then I can clean up the DTS files, and then 
> as far as I'm concerned, I'm done.

I think you're on the right track and we are talking past
each other somehow.  We'll see :-)


More information about the Linuxppc-dev mailing list