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

[Mike Frysinger <vapier@gentoo.org>]

On Friday 30 April 2010 08:40:21 Detlev Zundel wrote:
> > 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.
> 
> For the direction we have taken, I consider this to be a completion of
> the path.  Actually I did not realize that we had such a mac-programming
> in "setenv" at all and that Mike explicitely took it out, but I realized
> that we certainly would need such a thing.  I considered it to be much
> easier hoewever once we have such a method of the netdevice.

you seem to be confused by what that code actually did.  it never programmed 
the mac in the hardware, it synced the eth_device and the environment.  the 
behavior we have today is exactly the same before that series of commits i 
referenced.  i simply standardized things across the board and unified heavily 
duplicated behavior.  what i'm talking about adding here is different from 
what used to be there ... it's just that the mechanism is the same.

> > 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.
> 
> We are aiming at a level of consitency which we never had before, so I
> expect some changes.  They are quite small however and the amount of
> ongoing patches to adopt the new policy encourage me to be optimistic
> here ;)

there's going to be one patch for every driver.  just because only a few 
people have submitted patches for drivers they're interested in doesnt mean 
the overall thrashing is small.  a quick grep counts about 35 drivers that 
need updating.
-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/20100430/f9098326/attachment.pgp