[U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday 11 February 2009 00:45:05 Ben Warren wrote:
> Mike Frysinger wrote:
> > On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote:
> >> i think we can agree that this does not scale at all.  if, however, we
> >> change the global data to something like:
> >> typedef struct bd_info {
> >> 	...
> >> #ifdef CONFIG_NET_MULTI
> >> 	uchar bi_enetXaddr[CONFIG_NET_MULTI_MAX][6];
> >> # define bi_enetaddr bi_enetXaddr[0]
> >> #else
> >> 	uchar bi_enetaddr[6];
> >> #endif
> >> 	...
> >> };
> >
> > Ben: does this sound reasonable ?  if so, i can start a patch series
> > moving in this direction ...
>
> Thanks for tackling this cluster$%@#.  I'm not crazy about the
> CONFIG_NET_MULTI_MAX, but then I'm not really sure why the ethernet
> addresses exist in global data on boards with CONFIG_NET_MULTI.  The net
> library doesn't use them, most (maybe all?) of the drivers don't look at
> it.  Some common code does, but does it need to?  Maybe it's needed to
> pass to some operating systems?  This is an example of something that
> could use some serious refactoring, but I expect it's an onion with
> many, many layers.  OTOH, if you're going to change the name of a
> variable in global data, you'll find out really fast where it's used.
> Maybe we can gut it completely?  I'm lacking in historical perspective
> and my world view is pretty limited, so hopefully others (read WD) will
> chime in.

i provided a backwards compat define so no code would break:
# define bi_enetaddr bi_enetXaddr[0]

but simply dropping all bi_enet*addr consumption in global data sounds like 
one way of tackling the situation.  i see the structure as kind of a binary 
cache of the environment.  but as a cache, it certainly shows today that it 
gets out of sync and many places use only one or the other.  and with the 
utility functions i proposed, transitioning over to having the env be the only 
storage location wouldnt be too bad at all i dont think.
-mike