[U-Boot] [PATCH] Blackfin: bfin_mac: hook up new write_hwaddr function

[Mike Frysinger]

On Tuesday 27 April 2010 16:07:21 Ben Warren wrote:
> On 4/27/2010 12:32 PM, Mike Frysinger wrote:
> > your v4 patch writes the env to the hardware in the initialize() step,
> > not the init() step.  if someone changes ethaddr on the fly, the common
> > net funcs sync env->eth_device, but it does not call the new
> > write_hwaddr() func.  perhaps you intended to make that change, but it
> > currently doesnt do it.
> 
> I see.  I think this logic could use some rework.  It seems to me that
> we should only worry about sync'ing the device that we're trying to
> use.  If its address in the environment is different from the one in the
> device struct, we could sync and program, instead of doing all of them.
> Does that make sense?

the reason it's written the way it is currently is due to the list of eth 
drivers sometimes being used as a linked list and other times as an indexed 
array.  the two loops could probably be merged in eth_init(), but i dont think 
this overall will accomplish the new intended behavior.

if the new direction is to have the OS booted with the current correct MAC 
address programmed regardless of any net funcs being called, then the current 
logic in eth_initialize() will probably need to be replicated back into 
cmd_nvedit (see commit 56b555a644).  then the logic in eth_init() here can be 
dropped, and drivers themselves can lose the MAC programming in their init() 
funcs.

however, considering the number of drivers and thrashing this policy is 
causing, and the intent for this to be a stop gap measure, i'm not sure we 
should change the init() func in drivers to stop programming the MAC address.  
otherwise we're going to have to do this same thing yet again but in the 
reverse direction.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100427/154faf06/attachment.pgp