From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Mon, 10 Dec 2007 15:28:40 -0500 Subject: [U-Boot-Users] [PATCH] ARM: add support of CONFIG_LAST_STAGE_INIT for arm In-Reply-To: <20071210185827.4f3c005b@dhcp-252-066.norway.atmel.com> References: <20071209145042.C7E41247F5@gemini.denx.de> <475C19F5.4090507@discworld.dascon.de> <20071210185827.4f3c005b@dhcp-252-066.norway.atmel.com> Message-ID: <475DA178.4040000@qstreams.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Haavard Skinnemoen wrote: > On Sun, 09 Dec 2007 17:38:13 +0100 > Michael Schwingen 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