[U-Boot] Setting up MAC address for eth drivers

[Joe Hershberger <joe.hershberger@gmail.com>]

Hi Michal,

On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek <michal.simek@xilinx.com>
wrote:
>
> Hi,
>
> I have a question regarding setting mac address for drivers.
> Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize
> which is called from common/board_r.c.

This is because on at least ARM kernels, the MAC is passed via the MAC's
filter registers. Because of this, we need to write hwaddr even before the
MAC is started.

> But then there are some drivers(macb, designware, altera_tse) which also
calls
> mac setup from dev->init which has side effect for example when you setup
CONFIG_ENV_OVERWRITE
> and change mac address you can directly use it.

This is probably a work-around for a shortcoming of the net/eth.c not
calling write_hwaddr() when the env MAC changes. It already updates the
registers used by the network stack, so presumably if those MACs are
filtering incoming traffic based on the register as expected, changing the
MAC after boot without rewriting that register would cause all traffic to
not be returned.

> It also means if there is intention to call hwaddr from dev->init
> that for the first packet mac address is setup twice - in eth core init
> and then before every driver use.

The design of the network stack assumes the MAC is started each time a
network operation is requested and stopped when done.

As for the setting of the hwaddr, we should check if it changed.

> I am asking this question because I would like to know the right flow
> for eth mac setup.
> If it is
> set ethaddr xx....
> saveenv
> reset
> eth with new mac
>
> or if
> set ethaddr
> eth with new mac
> should work
>
> The second approach looks reasonable when ethaddr is not set at all
> but then at least our driver needs to be fixed to support this feature.

I think the second should work ideally, but we need to add a call to
eth_init() if the "ethaddr" in the env changes and set it again if so. We
should also remove the calls from the drivers you identified since the
framework will now do it.

Cheers,
-Joe