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

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