Hi Mike and Ben,
> if the new direction is to have the OS booted with the current correct MAC
> address programmed regardless of any net funcs being called, then the current
> logic in eth_initialize() will probably need to be replicated back into
> cmd_nvedit (see commit 56b555a644). then the logic in eth_init() here can be
> dropped, and drivers themselves can lose the MAC programming in their init()
> funcs.
For the direction we have taken, I consider this to be a completion of
the path. Actually I did not realize that we had such a mac-programming
in "setenv" at all and that Mike explicitely took it out, but I realized
that we certainly would need such a thing. I considered it to be much
easier hoewever once we have such a method of the netdevice.
> however, considering the number of drivers and thrashing this policy is
> causing, and the intent for this to be a stop gap measure, i'm not sure we
> should change the init() func in drivers to stop programming the MAC address.
>
> otherwise we're going to have to do this same thing yet again but in the
> reverse direction.
We are aiming at a level of consitency which we never had before, so I
expect some changes. They are quite small however and the amount of
ongoing patches to adopt the new policy encourage me to be optimistic
here ;)
Cheers
Detlev
--
We can forgive a man for making a useful thing as long as he does not
admire it. The only excuse for making a useless thing is that one
admires it intensely.
--- Oscar Wilde
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
