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

[Simon Glass]

Hi,

On 17 March 2015 at 11:47, Michal Simek <michal.simek at 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.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.

This is in u-boot-dm/next now.

Regards,
Simon