On Wednesday 02 June 2010 21:57:42 Heiko Schocher wrote: > Actual fec_mxc.c driver is *not* correct, because if in eeprom > is a correct mac, it *always* programms this in the mac address > registers from the chip! > > This is not OK, and must be fixed!
i agree 100% > > 2. Read from environment in net/eth.c after initialize() > > 3. Give priority to the value in the environment if a conflict > > 4. Program hardware in the device's init() function. > > > > If somebody wants to subvert the 'design philosophy', the right way is > > to call eth_dev->init() in board code. > > Maybe this list should go in a doc? the 1. - 4. is already in the documents ive mentioned multiple times, but they arent short & to the point like Ben has summarized, so that would probably be good to add as a summary and/or intro to one of them. Ben's suggestion on how to "subvert" things by forcibly calling eth_dev- >init() sits best in my book for people insisting on throwing in a hack today. it could even be done today in the board-specific board_eth_init() function by calling eth_init() after all the NICs have been registered. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
