[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