From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Wed, 31 Mar 2010 02:07:54 -0400 Subject: [U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup In-Reply-To: <4C070C16.5000001@denx.de> References: <4BB238E9.7060609@denx.de> <4BB2785B.50003@gmail.com> <4C070C16.5000001@denx.de> Message-ID: <201003310207.56010.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100331/d520b6e8/attachment.pgp