[PATCH 10/17] bootwrapper: Add dt_set_mac_addresses().
Timur Tabi
timur at freescale.com
Thu Mar 22 02:15:01 EST 2007
Segher Boessenkool wrote:
>> 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 :-)
I'm working on it.
> It's a layering violation anyway, a device
> driver has no business peering at "mac-address", that's info
> for a way higher layer ;-)
Eh, I don't think I agree with that. mac-address is supposed to be used
if it exists, because it represents the "most recent MAC address". If
it's not set, then the driver checks local-mac-address.
See of_get_mac_address(), which I wrote.
>> 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.
I don't consider it a hack. The U-Boot code checks for mac-address, and
then updates it if it exists. Then it checks for local-mac-address and
does the same. I don't see this code changing ever, because we're
always going to need to support older device trees that don't have just
local-mac-address.
>> 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).
Ok.
More information about the Linuxppc-dev
mailing list