[U-Boot] [RFC] Program net device MAC addresses after initializing

[Ben Warren]

On 4/9/2010 12:58 PM, Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message<4BBB6470.30604 at 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