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

[Ben Warren]

On Sat, Mar 22, 2008 at 10:01 AM, Wolfgang Denk <wd at denx.de> wrote:
> In message <200803221114.40956.sr at denx.de> you wrote:
>  >
>  > > In message <200803220731.23229.sr at denx.de> you wrote:
>  > > > I would prefer to move this init code not into the board code but into
>  > > > the platform/cpu code. Speaking for PPC4xx, here all configuration I know
>  > > > of have the same init code. And copying this into all board ports instead
>  > > > on one place in the cpu directory seems "imperfect".
>  > >
>  > > But the ethernet configuration *is* actually bord dependent. A  board
>  > > may  or  may  not  use  all  the  ethernet  interfaces  present  on a
>  > > processor, or it may have additional network controllers attached for
>  > > example to the PCI bus, etc.
>  >
>  > So you vote for adding this code to more than 80 4xx boards that all would use
>  > the same code here? I don't like this. I would prefer one instance in the cpu
>  > directory which could be overridden if needed by a board specific version.
>
>  We agree that this should be implemented at the highest possible
>  level, i. e. with touching as little files as possible.
>
>  I just wanted to point out that this is  actually  a  board  specific
>  thing, while you said "all configuration I know of have the same init
>  code."
>
>  All I'm asking for is to make sure that this can be configured  in  a
>  board  specific  way.  If  there  is a zensible default setting which
>  covers most cases without need for board-specific stuff  that's  just
>  all the better.
>
How about something like this:

#ifdef CONFIG_ETH_INIT_DEFAULT
        CFG_ETH_INIT_DEFAULT(bis);
#else
        board_eth_init(bis);
#endif

and then in your 4xx header files put

#define CONFIG_ETH_INIT_DEFAULT
#define CFG_ETH_INIT_DEFAULT(x) ppc_4xx_eth_initialize(x)

OTOH, what I really want to do is gut the concept of drivers getting
configuration info from board header files.  For example, I'd much
rather have board code pass PHY information to the driver than have
the driver get it via #CONFIG ETH1_PHY_ADDR, if you know what I mean.
Obviously, getting to that point is a huge undertaking probably
touching hundreds of files.  I'm willing to do it as long as resources
exist to test on hardware that I don't have.

regards,
Ben