From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Thu, 08 Apr 2010 17:30:05 +0200 Subject: [U-Boot] [RFC] Program net device MAC addresses after initializing In-Reply-To: <4BBB6470.30604@gmail.com> (Ben Warren's message of "Tue, 06 Apr 2010 09:42:24 -0700") References: <1270450929-17004-1-git-send-email-biggerbadderben@gmail.com> <20100406125755.681E6104D38D@gemini.denx.de> <4BBB6470.30604@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Ben, >>> Add a new function to the eth_device struct for programming a network >>> controller's hardware address. >>> >>> After all network devices have been initialized and the proper MAC address for >>> each has been determined, make a device driver call to program the address >>> into the device. Only device instances with valid unicast addresses will be >>> programmed. Thanks for picking up this thread again. >>> This is a significant departure from existing U-boot behavior, but costs very >>> little in startup time and addresses a very common complaint among developers. As I have discovered, there are a few device drivers _currently_ doing this. So actually we will close the gap of documentation/current practice/design goals. >> The thing is that this _is_ a violation of the design rules, and we >> should not make assumptions that such an initialization is harmless >> for all systems. >> >> > I know this differs from the existing design rules. I'm not trying to > be subtle or create a loophole, I'm trying to change policy. You'll > notice that by itself, this patch does nothing other than chew up a few > CPU cycles and bytes of flash. I second this effort - actually I had a patch looking very much the same in my repository. I wanted to attach it to an existing driver before posting it, but this is just as good. >> From the patch it is not clear to me who is supposed to implement >> write_hwaddr() - it should be made clear that this should be be done >> only when absolutely necessary, and then best in board specific code, >> >> > The new function is part of the 'eth_device struct', so will be > implemented in the network drivers. As designed, MAC addresses will be > programmed on all controllers that have a valid entry either in their > NVRAM or the environment. If somebody goes to the effort of putting a > valid address in one of these places, we should assume that he or she > wanted it to be used. If there is no such entry or the driver doesn't > implement this method, nothing happens. I have an idea for providing a > board-level 'opt-out' ability, but doubt that it would be used much. As stated above, I also would have implemented it inside of a netword driver and thus not at a board level. > I'm interested in knowing use cases where programming a MAC address is > harmful, keeping in mind that this new code only programs valid MAC > addresses.