[U-Boot-Users] [RFC][PATCH 1/1] Add board_eth_init() function
Andy Fleming
afleming at gmail.com
Tue Mar 25 18:04:31 CET 2008
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
More information about the U-Boot
mailing list