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

From: Segher Boessenkool <[email-masked]>
Date: Wed, 21 Mar 2007 22:54:19 +0100

>>> 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 :-)

Segher