[U-Boot] [PATCH 1/2 v2] net, fec_mxc: only setup the device enetaddr with eeprom value, if ethaddr is not setup

[Detlev Zundel <dzu@denx.de>]

Hi Ben,

> Hi Detlev,
>
> On Wed, Mar 31, 2010 at 6:44 AM, Detlev Zundel <dzu@denx.de> wrote:
>
>     Hi Ben,
>
>     > Hold on a second. ?This patch is wrong. ?As Mike has pointed out, the
>     > net library already gets the MAC address from the environment. ?The
>     > correct flow is:
>     >
>     > 1. Read from hardware in initialize() function
>     > 2. Read from environment in net/eth.c after initialize()
>     > 3. Give priority to the value in the environment if a conflict
>     > 4. Program hardware in the device's init() function.
>     >
>     > If somebody wants to subvert the 'design philosophy', the right way is
>     > to call eth_dev->init() in board code.
>
>     This would mean that for the real problem of a missing mac address, the
>     device then is initialized completely adding the autonegotation timeout
>     to every bootup sequence, correct?
>
>
> My suggestion here is a crude hack, and definitely does more than needed. ?It
> has the advantage of having narrow scope (is limited to the board in
> question).?

This specific problem in the meantime hit me on multiple arm boards with
different network interfaces so I think it has a broader audience than a
single board.

>     If it is, then it doesn't solve my problem in an acceptable way. ?On the
>     other hand a different route occured to Wolfgang and me in a lengthy
>     discussion. ?This will need a little broader interpretation of the
>     design guidelines, but as I still cannot see any downside to this and it
>     will also fix some inconsistent behaviour _that we currently have_
>     ("setenv ethaddr ...", do not do any network transfer and boot linux), I
>     want to follow this route.
>
>     I will try to implement this in form of a patch in order to keep the
>     discussion close to the effects on the code base.
>
>
> I'm looking forward to seeing what you come up with. ?I personally don't have a
> problem with adding the few ns to boot-up time that programming an SOC's MAC
> would take, but dislike the piece-meal approach that's been done so far.?

I fully agree.  Previously I was under the impression that we already
have a "fast initialization" (probe) and a "full initialization" (init)
of the network interfaces, where programming the mac would (on a first
stab) fit into the probe part (and some drivers obviously do/did this).

In the meantime it seems like it is a broader problem of keeping
"ethaddr" and friends in sync with the real hardware.  Although this is
something I personally always took for granted, it currently is most of
the time but not always correct.

If we solve the latter problem in a nice way, the initial problem will
simply disappear (or so I hope) ;)

Cheers
  Detlev

-- 
You live and learn
--
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: dzu at denx.de