Hi Gary,
Gary Jennejohn wrote:
On Thu, 13 Nov 2008 09:30:51 -0800 Ben Warren biggerbadderben@gmail.com wrote:
Heiko Schocher wrote:
Hello Ben
Ben Warren wrote:
Heiko Schocher wrote:
Check the presence of the PIGGY on the keymile boards mgcoge, mgsuvd and kmeter1. If the PIGGY is not present, dont register this Ethernet device.
Signed-off-by: Heiko Schocher hs@denx.de
This looks like useful stuff to have, but I'd prefer that you put the check logic in board_eth_init() rather than adding to the individual device drivers. I know the 8260 SCC driver is the older style, which precludes the use of board_eth_init, but I'll convert it if you're able to test.
Unfortunately, this approach won't work. First of all, the 82xx SCC driver is now initialized in cpu_eth_init(), which knows nothing about board-specific peculiarities like the PIGGY. Secondly, the HDLC driver for Keymile has to be initialized in board_eth_init(), and it has nothing to do with the PIGGY. Putting the check in board_eth_init() would break it completely. I looked at Heiko's latest patch and couldn't figure out a way to cleanly differentiate between initializing the HDLC driver and checking whether the PIGGY was present fo the other ENET drivers.
I think you're missing something. You can put whatever logic you want in board_eth_init(), *including* calling cpu_eth_init(). As long as board_eth_init() returns >= 0, cpu_eth_init() will never get called by eth_initialize(). When I designed this, my intention (although not well communicated) was that board_eth_init() would always return >= 0, and that the -1 return code would only be used by the weak function in net/eth.c There's pretty serious flexibility here and I urge you to look again.
regards, Ben