From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Warren <biggerbadderben@gmail.com>
Date: Fri, 09 Apr 2010 17:34:12 -0700
Subject: [U-Boot] [RFC] Program net device MAC addresses after
	initializing
In-Reply-To: <20100409195856.507C919F36@gemini.denx.de>
References: <1270450929-17004-1-git-send-email-biggerbadderben@gmail.com>
	<20100406125755.681E6104D38D@gemini.denx.de>
	<4BBB6470.30604@gmail.com>
	<20100409195856.507C919F36@gemini.denx.de>
Message-ID: <4BBFC784.20604@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 4/9/2010 12:58 PM, Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message<4BBB6470.30604@gmail.com>  you wrote:
>    
>> 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.
>>      
> I think such an 'opt-out' ability is important.
>
>    
>> 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.
>>      
> There are zillions of different Ethernet controllers out there. To be
> able to program the MAC you might need to
> - map the respective memory area first, i. e. twiddle memory
>    controller settings
> - power of the Ethernet controller (which might be kept powered off or
>    otherwise disable normally to minimize power consumption)
> - take the controller out of reset
> - configure clocks needed to breath life into the controller
> ...
>
> I don;t have a specific example in mind where it would actually cause
> harm, but we might run into such situations and should be prepared to
> handle them gracefully.
>
>    
OK.  The next spin will have an easy opt-out, apart from 'setenv 
eth1addr 00:00:00:00:00:00'
> Best regards,
>
> Wolfgang Denk
>
>    
regards,
Ben