Hi Michal,
On Tue, Mar 17, 2015 at 11:57 AM, Michal Simek michal.simek@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@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