On 4/9/2010 12:58 PM, Wolfgang Denk wrote: > 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. > > OK. The next spin will have an easy opt-out, apart from 'setenv eth1addr 00:00:00:00:00:00' > Best regards, > > Wolfgang Denk > > regards, Ben
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot