Dear Mike Frysinger,
In message <1234596190-524-3-git-send-email-vap...@gentoo.org> you wrote:
> Signed-off-by: Mike Frysinger <vap...@gentoo.org>
> CC: Ben Warren <biggerbadder...@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 usage
> + in 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
--
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
Real Programmers always confuse Christmas and Halloween because
OCT 31 == DEC 25 ! - Andrew Rutherford (andr...@ucs.adelaide.edu.au)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
