Re: mac-address vs. local-mac-address

[Kumar Gala <galak@kernel.crashing.org>]

On Feb 7, 2007, at 3:42 PM, Timur Tabi wrote:

> Benjamin Herrenschmidt wrote:
>> On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
>>> Hi everyone,
>>>
>>> What is the current consensus on using mac-address vs. local-mac- 
>>> address in the
>>> device tree?  The 1275 spec says this:
>>>
>>> "local-mac-address" Standard property name to specify preassigned  
>>> network address.
>>> "mac-address" Standard property name to specify network address  
>>> last used.
>>>
>>> I think we need to agree on some interpretation of these  
>>> statements, and all the
>>> code should be updated to implement that interpretation.
>>
>> It's fairly clear:
>>
>> local-mac-address is what is statically set by the firwmare (comes  
>> from
>> EEPROM, whatever).
>>
>> mac-address is really only meaningful if your firmware is
>> "dynamic" (real OF, uboot maybe) and was, for some reason,  
>> instructed by
>> the user to use a different mac address for that boot (if that  
>> feature
>> exist).
>>
>> It's basically the mac-address that was actually used on that  
>> interface
>> to netboot the kernel I'd say.
>>
>>> Linux doesn't support that.  In some cases, the actual device  
>>> tree is located on
>>> a TFTP server, and it's only copied temporarily into RAM by U- 
>>> Boot.  There's no
>>> way that a Linux driver can update that.
>>
>> I don't understand what you mean here :-) The linux driver can  
>> perfectly
>> well update the in-memory copy of the device-tree, which would  
>> make it
>> useful in the case of a kexec to a newer kernel.
>
> That makes sense.  I don't know anything about kexec, so I didn't  
> think there
> was any point in updating the in-memory copy.  But in this case,  
> the driver
> should update it.
>
>>> On a full-blown OF machine, the firmware does provide APIs for  
>>> updating the
>>> device tree, and so we could support mac-address on these  
>>> machines.  But U-Boot
>>> disappears once the kernel loads, so there is no firmware to call  
>>> to update the
>>> device tree.
>>
>> I don't understand what the firmware device-tree has to do with  
>> that...
>
> Without a firmware device tree, there's no way to update the device  
> tree and
> have that new tree retained over a reboot.
>
>> If uboot is instructed to use a different mac-address than the
>> "built-in" one, it can perfectly well create that property before
>> getting to the kernel.
>
> And it does, depending on which version of U-Boot.  There is debate  
> (inside
> Freescale, at least) whether U-Boot should update mac-address or
> local-mac-address.  It sounds to me like it should update local-mac- 
> address, and
> the DTS file shouldn't even include an entry for mac-address.

The problem with u-boot is that the correct way would be to use local- 
mac-address for what's compiled into u-boot and mac-address if  
someone does a 'setenv' to modify the mac address.  The question is  
anyone really going to care that much.

- k