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

[Ben Warren]

Hi Wolfgang,

On 4/6/2010 5:57 AM, Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message<1270450929-17004-1-git-send-email-biggerbadderben at gmail.com>  you wrote:
>    
>> 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.
>>
>> 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.
>>      
> 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.
>  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.

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.

> The patch should add such a description to the documentation.
>    
Absolutely.  This is an RFC and if we can reach agreement that it's a 
good thing, all the appropriate documentation will be revised.
> Also, we should remove / adapt existing code that performs basicly the
> same action.
>    
Most if not all drivers currently have a private function for 
programming MAC addresses.  We can either modify them as time goes by, 
or I'll take on the effort of fixing them all up with the obvious caveat 
that very little testing will be performed by me.
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
>    
regards,
Ben