Dear Ben Warren, In message <4bbb6470.30...@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: w...@denx.de Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot