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

Olof Johansson olof at lixom.net
Thu Mar 22 07:22:11 EST 2007

On Wed, Mar 21, 2007 at 03:03:07PM -0500, Timur Tabi wrote:
> Segher Boessenkool wrote:
> >> 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?  You need to make sure that both use the same address.  I don't think the kernel 
> command line supports MAC addresses.
> > 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?

Why? It's a property of the device -- the mac address it was assigned by
the vendor. It might not be a property of the ethernet controller chip,
but of the adapter it is.

> 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 

Right, there's no other place that makes sense. Leave it in there.

> 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.  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.

We're using them in our driver/device tree as well.


More information about the Linuxppc-dev mailing list