PATCH: support board-specific ethernet PHY init for ARM

Hi,

The following patch adds support for board-specific PHY initialization on ARM targets (IXP42x in my case), similar to the PPC board code.

I have one boards where the LED pins on the PHY need to be setup to function properly, and one board where the ethernet switch starts up with all ports disabled.

Signed-off-by Michael Schwingen <[email protected]>

lib_arm/board.c +0 -0

index 7e97f13..c5a941d 100644

The phy reset will be call in the mac layer drivers not in the board part.

Quoted 3 lines · Jean-Christophe PLAGNIOL-VILLARD

The phy reset will be call in the mac layer drivers not in the board part.

It seems I am a bit lost in the network code.
As I see it, I have to place board-specific PHY reset code after the call to eth_initialize in board.c, but before main_loop. If there is already such a hook in generic code, could you please tell me where?

Signed-off-by Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

lib_arm/board.c +1 -0

index 6f35aa0..0eadc3a 100644
@@ -431,6 +431,14 @@ extern void dm644x_eth_set_mac_addr (const u_int8_t *addr);
 #endif
 	eth_initialize(gd->bd);
 #endif
+#ifdef CONFIG_LAST_STAGE_INIT

lib_arm/board.c extern void dm644x_eth_set_mac_addr (const u_int8_t *addr); · line 441

Quoted 11 lines

#endif

lib_arm/board.c +8 -0

 	eth_initialize(gd->bd);
 #endif
+#ifdef CONFIG_LAST_STAGE_INIT
+	/*
+	 * Some parts can be only initialized if all others (like
+	 * Interrupts) are up and running (i.e. the PC-style ISA
+	 * keyboard).
+	 */
+	last_stage_init ();
+#endif

Please, not yet another such thing.

Is there any specific reason why you cannot use any of the existing entry points, like for example board_late_init() ?

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.

Quoted 4 lines · On Sun, 09 Dec 2007 17:38:13 +0100 Michael Schwingen…

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.

Quoted 9 lines · Haavard Skinnemoen

Quoted 4 lines · On Sun, 09 Dec 2007 17:38:13 +0100 Michael Schwingen…

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.

Quoted 4 lines

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

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.

In message <[email protected]> you

Quoted 3 lines

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.

Please keep in mind that U-Boot shall initialize hardware if and only if it is using it (and that it must deactivate it after use).

Quoted 3 lines

Please keep in mind that U-Boot shall initialize hardware if and only if it is using it (and that it must deactivate it after use).

with many pieces of hardware, you can draw a line between initializing it and actually enabling/using it.

for example, shouldnt the initialization/programming of the MAC address always happen regardless of the network being used ? not all MAC's have/support

eeprom's which contain the MAC address, so the implicit address programming that happens in hardware cannot happen.

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.

Quoted 4 lines · Haavard Skinnemoen

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.

That may depend on board/PHY: on some PHYs, the LED pin functions need to be set in software, so on power-up the ethernet LEDs may light up and display bogus states, so I would prefer to configure that early, even if the port is not used.

Quoted 5 lines

That may depend on board/PHY: on some PHYs, the LED pin functions need to be set in software, so on power-up the ethernet LEDs may light up and display bogus states, so I would prefer to configure that early, even if the port is not used.

I think that things like this should be done in board specific init code, then.