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

[Ben Warren]

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.
>
>   
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.

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. 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().

Thoughts?

regards,
Ben