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

Segher Boessenkool segher at kernel.crashing.org
Thu Mar 22 00:45:36 EST 2007


> Normally, that's true.  The problem is that device drivers first check 
> mac-address and
> then local-mac-address (see of_get_mac_address()).  If the DTS define 
> mac-address as
> something other than 00-00-00-00-00-00, the drivers are going to see 
> mac-address that and
> use it.

So fix that :-)  It's a layering violation anyway, a device
driver has no business peering at "mac-address", that's info
for a way higher layer ;-)

> Obviously, the DTS files shouldn't have mac-address in them.  But I 
> haven't gotten around
> to cleaning that up, because I'm still waiting for the U-Boot 
> maintainers to apply my
> pre-requisite patches.

Well there's that, sure.  Please put comments in your source
code saying this _is_ a hack and for _what_ and that it should
be removed when your dependency is fixed, and all is fine.

> Perhaps mac-address should be deleted instead of just ignored?

That would be incorrect behaviour if you get passed a device
tree where "mac-address" is correctly set (i.e., the device
has been used for booting, or something).

> I think it's better if the DTS only specifies properties that the 
> bootloader can't.  We
> already need the ability to insert properties, so what's wrong with 
> using that?

Agreed.  It was good before, when the tools weren't powerful
enough; but now it's hardly worth saving a few cycles.

> I think
> it doesn't make sense for the DTS to specify a MAC address.

In a few cases it might (during development, for example).
Or maybe a crazy firmware passed you a DTS instead of a DTB,
who knows ;-)


Segher




More information about the Linuxppc-dev mailing list