[U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200902021505.17476.vapier at gentoo.org> you wrote:
>
> how about this document at doc/README.enetaddr ...

Thanks!

> ---------------------------------
>  Ethernet Address (MAC) Handling
> ---------------------------------
>
> There are a variety of places in U-Boot where the MAC address is used, parse,

parsed

> Here are the places where MAC addresses are stored:

...where MAC addresses may be stored.

>  - board-specific location (eeprom, dedicated flash, ...)

Please add:

	Note: only used when mandatory due to hardware ddesign etc.

>  - environment ("ethaddr", "eth1addr", ...)

Please add:

        Note: this is the preferred way to permanently store the MAC
        addresses in U-Boot.

>  - global data (bi_enetaddr, bi_enet1addr, ...)
>  - ethernet data (struct eth_device -> enetaddr)

Please add:

	Note: these two are just temporary copies of the MAC address,
	which exist only after running the respective initialization
	code.

> -------
>  Usage
> -------
>
> During board init (like the board-specific misc_init_r() function), boards
> should take care of locating the MAC address, initializing the environment,
> and seeding the global data.

Please change:

	If the hardware design mandates that the MAC address is stored
	in some special place, like EEPROM etc., then the board
	specific init code (like the board-specific misc_init_r()
	function) is responsible for locating the MAC address(es) and
	initialize the respective environment variable(s) from it.

        Note that this shall be done if, and only if, the environment
        does not already contain these environment variables, i. e.
        existing variable definitions must not be overwritten.

	The envrionment handling code (function setevn()) will update
	the global data accordingly.

> During runtime, the ethernet layer will use the environment variables to sync
> the MAC addresses to the ethernet structures.  All ethernet driver code should
> then only use the enetaddr member of the eth_device structure.

Please change:

	During runtime, the ethernet layer will use the global data
	to sync ...

> The common environment code will take care of passing environment changes to
> the global data and to the ethernet layer.

Maybe again refer to setenv(). Note  that this updates only the global
data. The ethernet layer shall init any internal structures it needs
when it runs it's own init code, i. e. upon invocation of a network
related command.

> 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.

Any code that wishes to access the MAC address should then query the
global data or the environment, depending on whatever (binary or
string representation) seems more appropriate.

> 	* bool eth_getenv_enetaddr(char *name, uchar *enetaddr);

Make this "int" - we don't use "bool" in U-Boot. This is C code.

> Look up an environment variable and convert the stored address.  If the env var
> is not set, then the function returns false.  Otherwise, the conversion occurs
> and returns true.

s/false/-1/; s/true/0/;

> uchar enetaddr[6];
> if (eth_getenv_enetaddr("ethaddr", enetaddr))
> 	/* enetaddr is now set to the value stored in the ethaddr env var */
> else
> 	/* "ethaddr" is not set in the environment */

	if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
		/* "ethaddr" is not set in the environment */
		...
	}
	/* enetaddr is now set to the value stored in the ethaddr env var */


Thanks again.

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: wd at denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is  a  nanocentury.
                                               -- Tom Duff, Bell Labs