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

[Ben Warren]

On 3/25/08, Andy Fleming <afleming at gmail.com> wrote:
> 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
>

With the current incarnation of network code, that would be a common
use case.  However, I really don't like having interface-specific
#defines in the config file, since it doesn't jibe well with kconfig
and is just ugly.  You know what I'm talking about - #define
CONFIG_TSEC1_PHY_FLAGS etc. (I made this up, but I'm sure there are
definitions like it)  The main reason I went through this exercise is
to move towards a point where all but the most trivial Ethernet
controllers are initialized in board code, allowing us to pass PHY
info, feature flags etc. on a per-interface basis.

regards,
Ben