mac-address vs. local-mac-address

Timur Tabi timur at freescale.com
Thu Feb 8 08:17:43 EST 2007


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.

My interpretation is that mac-address is supposed to the contain these MAC 
addresses under these circumstances:

1) If the Ethernet interface is up, it's the MAC address that is currently in use.
2) If the Ethernet interface is not up, it's the MAC address that was in use the 
last time the Ethernet interface was shut down.

In Linux, the ifconfig command is used to change the MAC address.  This command 
calls the driver's set_mac_address function, so it is the driver that sets the 
MAC address in the hardware.

In order to properly support the mac-address property, the driver must also 
update the device tree with the new MAC address.  That's the only way that 
mac-address can contain the "specify network address last used".

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.

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.

Therefore, I propose that on systems where the driver cannot update the device 
tree, the mac-address property should be absent from the device tree.  U-Boot 
should not add one, and the Linux device drivers should not reference it.

Comments?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale



More information about the Linuxppc-dev mailing list