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

[Michal Simek]

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.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.

That's fine.

Thanks,
Michal