[U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup

[Ben Warren]

Hi Mike,

On 3/31/2010 12:59 PM, Mike Frysinger wrote:
> On Wednesday 31 March 2010 10:46:25 Detlev Zundel wrote:
>    
>> I fully agree.  Previously I was under the impression that we already
>> have a "fast initialization" (probe) and a "full initialization" (init)
>> of the network interfaces, where programming the mac would (on a first
>> stab) fit into the probe part (and some drivers obviously do/did this).
>>
>> In the meantime it seems like it is a broader problem of keeping
>> "ethaddr" and friends in sync with the real hardware.  Although this is
>> something I personally always took for granted, it currently is most of
>> the time but not always correct.
>>
>> If we solve the latter problem in a nice way, the initial problem will
>> simply disappear (or so I hope) ;)
>>      
> the latter problem is already solved in the general case.  the first
> initialize path gets the hw mac address and gives it to the common layers.
> common layers take care of keeping the structures in sync.  when the slow init
> path gets called to actually bring up the hardware, the mac has already been
> synced to the structures.  correctly written devices never have to care about
> anything other than dev->enetaddr and should not be programming the MAC with
> the MAC address in the fast initialize path.
>
> really what you want is a new eth entry point like eth_write_mac() that goes
> through the common layers and programs the MAC with the MAC address.  this
> isnt a problem with the current net framework.
>    
Detlev and I were just talking off-list about exactly that.  I guess 
'great minds think alike', as my grandma used to say.
> -mike
>    
regards,
Ben