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

[Timur Tabi <timur@freescale.com>]

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.