Dear Mike Frysinger,
In message 1234596190-524-3-git-send-email-vapier@gentoo.org you wrote:
Signed-off-by: Mike Frysinger vapier@gentoo.org CC: Ben Warren biggerbadderben@gmail.com
doc/README.enetaddr | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 96 insertions(+), 0 deletions(-) create mode 100644 doc/README.enetaddr
...
+Here are the places where MAC addresses might be stored:
- board-specific location (eeprom, dedicated flash, ...)
- Note: only used when mandatory due to hardware design etc...
- environment ("ethaddr", "eth1addr", ...) (see CONFIG_ETHADDR)
- Note: this is the preferred way to permanently store MAC addresses
- ethernet data (struct eth_device -> enetaddr)
- Note: these are temporary copies of the MAC address which exist only
after the respective init steps have run and only to make usagein other places easier (to avoid constant env lookup/parsing)
- struct bd_info and/or device tree Note: these are temporary copies of the MAC address only foir the purpose to pass this information to an OS kernel we are about to boot
+The common environment code will take care of passing environment changes to +the global data. This happens automatically whenever setenv() updates the +relevant ethaddr variables.
Didn't we just remove the MAC address information from the global data?
+Any other common code that wishes to access the MAC address should then query +the global data directly. No one should be looking in the environment for any +addresses.
Is this still valid?
+Print the MAC address into the specified storage. Caller should make sure the +storage is sufficient (20 bytes is fine). The pointer used for storage is +returned. +char buf[20]; +uchar enetaddr[6] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55 }; +str_enetaddr(buf, enetaddr); +printf("The MAC is %s\n", buf); +/* the buf variable is now set to "00:11:22:33:44:55" */
I think we should instead borrow the 'M' (and probably also the 'I', but that's a different story) format specifiers from the Linux "lib/vsprintf.c" implementation ?
Best regards,
Wolfgang Denk