On Tue, Mar 25, 2008 at 11:33 AM, Stefan Roese <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
