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

[Joe Hershberger]

Hi Michal,

On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek <michal.simek at xilinx.com>
wrote:
>
> Hi Joe,
>
> On 03/17/2015 04:56 PM, Joe Hershberger wrote:
> > Hi Michal,
> >
> > On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek <michal.simek at 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.
>
> Does it mean that you are going to write that code for it?

Yes... I'll write it, but it needs to be on top of the DM_ETH patches, so
I'll probably wait until that's pulled.

-Joe