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

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:16 Tue 10 Jun     , Ben Warren wrote:
> 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.
What about a section to declare the netdev?

In this case we can have more than 2 eth and it more generic.

Best Regards,
J.