On 4/27/2010 12:32 PM, Mike Frysinger wrote: > On Tuesday 27 April 2010 14:46:34 Ben Warren wrote: > >> On 4/27/2010 11:42 AM, Mike Frysinger wrote: >> >>> On Tuesday 27 April 2010 14:33:09 Ben Warren wrote: >>> >>>> On 4/27/2010 11:15 AM, Mike Frysinger wrote: >>>> >>>>> - bfin_EMAC_setup_addr(dev->enetaddr); >>>>> + bfin_EMAC_setup_addr(dev); >>>>> >>>> Are you sure you still want to program it on every init() call? There's >>>> nothing wrong with that, BTW... >>>> >>> that's the correct documented behavior ... otherwise, there's no way of >>> syncing the env to the hardware. this is init(), not initialize(). >>> >> Hardware will already be sync'd to the env, since write_hwaddr() now >> automatically gets called after initialize(). The only thing you gain >> from having this call in init() is to program hardware on interfaces >> that were skipped due to the 'ethmacskip' environment variable being set. >> > your v4 patch writes the env to the hardware in the initialize() step, not the > init() step. if someone changes ethaddr on the fly, the common net funcs sync > env->eth_device, but it does not call the new write_hwaddr() func. perhaps > you intended to make that change, but it currently doesnt do it. > -mike > I see. I think this logic could use some rework. It seems to me that we should only worry about sync'ing the device that we're trying to use. If its address in the environment is different from the one in the device struct, we could sync and program, instead of doing all of them. Does that make sense?
I'll take your patch and maybe next release we can work on improving this. regards, Ben _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot