Hi Wolfgang,
On 4/6/2010 5:57 AM, Wolfgang Denk wrote:
Dear Ben Warren,
In message1270450929-17004-1-git-send-email-biggerbadderben@gmail.com you wrote:
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.
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.
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.
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.
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.
The patch should add such a description to the documentation.
Absolutely. This is an RFC and if we can reach agreement that it's a good thing, all the appropriate documentation will be revised.
Also, we should remove / adapt existing code that performs basicly the same action.
Most if not all drivers currently have a private function for programming MAC addresses. We can either modify them as time goes by, or I'll take on the effort of fixing them all up with the obvious caveat that very little testing will be performed by me.
Thanks.
Best regards,
Wolfgang Denk
regards, Ben