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

[Wolfgang Denk]

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.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Men of peace usually are [brave].
	-- Spock, "The Savage Curtain", stardate 5906.5