On Dec 17, 2011, at 15:16, Wolfgang Denk wrote:
Dear Kyle Moffett, In message 1324001821-15337-1-git-send-email-Kyle.D.Moffett@boeing.com you wrote:
When using an offboard ethernet chip such as e1000, it is highly likely that the driver has already read a valid MAC address from the onboard EEPROM. In that case, U-Boot should not issue a warning about the absence of an "eth*addr" value in the environment.
Yes, it should. The rule is that then environment settings always have precedence, and if they are missing or contain different data than other sources for this information, a waning shall be printed.
That is a problem for devices which are typically add-in PCI cards. In that case U-Boot can't be expected to have knowledge of what the MAC addresses should be, and it should just use the ROM attached to the card instead.
In our use case the e1000 chips are on a separate board attached via CompactPCI. U-Boot should not spontaneously start throwing errors just because the board was stuck into a different slot or replaced due to hardware failure.
I was careful to maintain the behavior that U-Boot will issue a warning if there is no usable MAC address or if the environment has a MAC address that does not match the board.
However, in the case that the board itself has a valid external MAC address and U-Boot does not even have an environment variable, it should not cause extra messages. Think about hot-pluggable USB net adapters where the detection order is nondeterministic.
A properly configured HWW-1U-1A board is fixed from this output:
Net: e1000: 00:50:93:81:ff:8a e1000: 00:50:93:81:ff:8b owt0, owt1, peer, e1000#0 Warning: failed to set MAC address , e1000#1 Warning: failed to set MAC address
To this:
Net: e1000: 00:50:93:81:ff:8a e1000: 00:50:93:81:ff:8b owt0, owt1, peer, e1000#0, e1000#1
This is also not correct. There should never be any printing of the MAC addresses here.
The messages should be:
Net: owt0, owt1, peer, e1000#0, e1000#1
The "e1000" driver has always done that. I can submit a separate patch to fix that if you would like.
Furthermore, the log messages should avoid screwing up the "Net:" output formatting provided by the calling code, EG:
Net: eth0, eth1 [could not set MAC: 00:50:93:81:ff:8a], eth2
No. "could not set" is an error message, and deserves a separate line.
Ok, I will respin the patch so that errors show up like this:
Net: eth0, eth1, ERROR: Could not set MAC address: 00:50:93:81:ff:8a eth2
Is that OK?
Cheers, Kyle Moffett