[U-Boot-Users] [PATCH] ARM: add support of CONFIG_LAST_STAGE_INIT for arm

[Haavard Skinnemoen]

On Mon, 10 Dec 2007 15:28:40 -0500
Ben Warren <bwarren at qstreams.com> wrote:

> Haavard Skinnemoen wrote:
> > On Sun, 09 Dec 2007 17:38:13 +0100
> > Michael Schwingen <rincewind at discworld.dascon.de> wrote:
> >
> >   
> >> If we could move board_late_init after eth_initialize (ie. directly 
> >> before calling main_loop), that would work in my case, and would remove 
> >> the necessity for my reset_phy patch.
> >>     
> >
> > Or even better, move eth_initialize into the board code. That would
> > allow us to kill a ridiculous number of #ifdefs in net/eth.c and would
> > allow the board to do any fixups it needs before and after the generic
> > code.

To clarify: I don't think we should move all of eth_initialize into
board code, but I think the whole initialization process should
originate from board code; for example introduce a new function
board_eth_init() which calls eth_initialize() after initializing the
ethernet controllers. Then we can remove all the calls to
board-specific functions from the beginning of eth_initialize().

> eth_initialize() is definitely a mess, but I don't think moving it to 
> board code is the right thing to do. On the other hand, one thing I've 
> been thinking about was a new eth_initialze() that steps through an 
> array of board-defined controller configurations. This way we could 
> specify all sorts of information about controller type, PHY type, 
> addresses etc. on a per-controller basis, and of course provide default 
> macros to abstract away the mundane.

Yeah, that might make sense too. But then again, perhaps we should go
all the way and put all driver initcalls in an array and initialize all
of them from one common do_initcalls() function like Linux does.

> More to the problem seen here - IMHO, a MAC's initialize() function 
> shouldn't do anything other than populate and register one or more 
> ethernet devices with the network subsystem. Any PHY initialization 
> stuff should happen in the specific driver's init() function, which only 
> gets called when the port is used.

It should probably initialize the PHY interface (i.e. the MDIO
interface) early, but I agree that it should delay initializing the
actual PHY until it is needed.

> If you want to do initialization of 
> any aspect of a controller that isn't used by u-boot, it should be in 
> board-specific init code, and there should be a board-instantiable 
> global function that is guaranteed to be after all the common code 
> (immediately before the main loop begins). I haven't looked at the code 
> in a while, but I gather one of the problems here was that 
> board_late_init() (or whatever it's called) comes before 
> eth_initialize(). If that's really the case, we need a 
> board_really_late_init().

Or a board_eth_init(), which will simply call the generic
eth_initialize() and do any remaining fixups that depend on ethernet
being up and running after that. The advantage is that we won't need
yet another initcall in the arch code, we just need to replace one of
them.

Haavard