Hi Michal, On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek <michal.si...@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.si...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
