[U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27

[Ben Warren <biggerbadderben@gmail.com>]

Hi Alfred,

alfred steele wrote:
>> Thanks for your submission!
>>     
> What is the current design on the mxc fec interface's attainment of a
> MAC address. From the kernel driver it looks like it looks at the
> IIM(IC identification registers) on the MXC platform(like mx51/35) to
> look for a programmed mac address and then the set the fec mac to the
> same .
>
> Looks like with the current mxc_fec driver there is not support for
> the same. I am thinking of a mechanism to hardcode a fake MAC which
> would subsequently be picked up by the kernel without using the
> bd_info structure.
> Any comments/suggestions?
>
> -Alfred.
>   
I don't know much about this driver, but it appears to be doing things 
incorrectly.  The correct flow is as follows.  It is documented in 
'doc/README.enetaddr':

1. The driver's initialize() function read from NVRAM if available.  MAC 
address is stuffed into dev->enetaddr.  The initialize() function should 
not try to get the address from the environment, which is where the 
imx27 driver goes wrong.
2. After all drivers have been initialized, eth_initialize() ( in 
net/eth.c) reads from the environment.  If the value in the environment 
is valid and the value in dev->enetaddr is valid and both are different, 
the user is warned.  The value in the environment overwrites the value 
in dev->enetaddr
3. When a network operation is performed, the driver's init() function 
is called, which is where the address is programmed into the device.

As you can see, if the device is never used, step 3 is never exected and 
the device is never programmed.  This is how it's supposed to work, 
since the U-boot design philosophy dictates that hardware is never 
touched unless it is used in U-boot.  I'm pretty sure hard-coding a fake 
MAC address would run afoul of this rule.

regards,
Ben