On 3/25/08, Andy Fleming <[EMAIL PROTECTED]> wrote:
> 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
>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 ------------------------------------------------------------------------- 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
