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

[Detlev Zundel]

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.