[U-Boot-Users] [PATCH] Add mechanisms for CPU and board-specific Ethernet initialization

[Ben Warren <biggerbadderben@gmail.com>]

Shinya Kuribayashi wrote:
> Stefan Roese wrote:
>> On Tuesday 10 June 2008, Shinya Kuribayashi wrote:
>>>>> Shouldn't this be the other way around?
>>>>>
>>>>> +       if (board_eth_init(bis) < 0)
>>>>> +               eth_eth_init(bis);
>>>>>
>>>>> So that the board init routine can "overwrite" the cpu init version.
>>>> Yeah, I think you're right.  If board_eth_init() exists, it gets
>>>> highest priority.
>>> Just wondered, does that mean we could only have either cpu_eth_init or
>>> board_eth_init at a time?
>>
>> Not really. board_eth_init() could call cpu_eth_init() if necessary.
>
> Hm. What is cpu_eth_init for then? Just
>
>        board_eth_init(bis);
>
> seems to be enough for me. I also wonder where is the best place to have
> cpu_eth_init?
>
The cpu_init() was suggested by Stefan in our original discussion, when 
I only had the board function.  His perspective is ppc_4xx, where tons 
of CPUs and boards share the EMAC driver, and he didn't want to modify 
each board.  As you'll see in the discussion with JDL, it can probably 
apply to TSEC as well.
> I'm not going to argue with you, I'm just thinking about my targets. One
> of my targets has internal ethernet MAC, and its evaluation board has an
> on-board external PCI NIC. Another target has internal MAC, but doesn't
> have PCI NIC.
>
> I thought it'll be something like
>
>        cpu_eth_init(bis);
>        board_eth_init(bis);
>
The idea is that cpu_eth_init is a default for a CPU family, and 
board_eth_init is a board override, which can of course call cpu_eth_init.
> But again, I don't have strong opinions around here. Please go ahead.
>
>
> Thanks for your comments,
>
>  Shinya
>
Thanks for the discussion!

cheers,
Ben