Hi, On 17 March 2015 at 11:47, Michal Simek <michal.si...@xilinx.com> wrote: > Hi Joe, > > On 03/17/2015 06:21 PM, Joe Hershberger wrote: >> 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. > > That's fine.
This is in u-boot-dm/next now. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
