[U-Boot-Users] [RFC][PATCH 1/1] Add board_eth_init() function

[Andy Fleming]

On Tue, Mar 25, 2008 at 11:33 AM, Stefan Roese <sr at denx.de> wrote:
> On Tuesday 25 March 2008, Andy Fleming wrote:
>  > >  I thought about this some more, and the problem is that cpu_eth_init()
>  > > and board_eth_init() are mutually exclusive, with board_eth_init() having
>  > > a higher priority. I think the following will work, but would appreciate
>  > > some feedback.
>  >
>  > I'm not sure that's necessarily the case.  Imagine, for instance, an
>  > 85xx board that (for some reason) has on-board ethernet.  I believe
>  > some of the DS systems do this.  So the 85xx has 4 nics which the SOC
>  > knows how to initialize.  But the board has an additional driver to
>  > init.  Why not just allow them both?
>
>  Image a board that doesn't want all CPU (SoC) interfaces to get initialized.
>  If for such a board a cpu-specific init routine exists, there is no chance to
>  not enable (init) all those cpu interfaces as done in cpu_eth_init().
>
>  With this approach of mutually exclusive routines, it could define it's
>  board_eth_init() and init only the Soc interfaces really needed. Plus
>  additional ones of course.
>
>  Does this make sense?

Well, it makes sense to a degree.  However, we already have a
mechanism for enabling or disabling individual interfaces.  The config
file for each board can be used to determine which interfaces are
setup by the cpu_eth_init() function.  I don't really object to having
them mutually exclusive.  But I suspect the most common use case would
become:

board_eth_init()
{
     my_special_eth_init(bis);

     cpu_eth_init(bis);
}

And if everyone's going to do that, why bother making the functions
mutually exclusive?

Andy