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.
Best regards,
Wolfgang Denk