[U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage
Ben Warren
biggerbadderben at gmail.com
Wed Feb 11 21:15:22 CET 2009
Mike Frysinger wrote:
> On Wednesday 11 February 2009 07:17:39 Wolfgang Denk wrote:
>
>> Dear Ben Warren,
>>
>> In message <499265E1.4050903 at gmail.com> you wrote:
>>
>>> 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
>>>
>> Good point.
>>
>> Let's keep in mind that the global data sturcture is something which
>> is supposed to hold data at a time before we have a writable data
>> segment, i. e. the early boot phase before relocation to RAM.
>>
>> In this case it makes no sense to hold MAC addresses in the global
>> data, as any network activities can only be started after relocation
>> to RAM.
>>
>
> sounds good. and the place where the board mac init happens will be in an _r
> func, so no problems there with the board seeding the env ...
>
>
>>> 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 think if we touch it at all, we should do it Right (TM), i. e. move
>> this out of the global data.
>>
>
> ok, i'll start up a branch to do this conversion in my repo. i'm guessing Ben
> wont have a problem with someone doing the grunt work ;).
> -mike
>
Uh, yeah. Not a problem. Thanks!
Ben
More information about the U-Boot
mailing list