Hi,
On 28 October 2015 at 19:40, Bin Meng <bmeng...@gmail.com> wrote:
> Hi Joe,
>
> On Thu, Oct 29, 2015 at 4:52 AM, Joe Hershberger
> <joe.hershber...@gmail.com> wrote:
>> Hi Bin,
>>
>> On Tue, Oct 27, 2015 at 11:10 AM, Bin Meng <bmeng...@gmail.com> wrote:
>>> Currently in fdt_fixup_ethernet() the MAC address fix up is
>>> handled in a loop of which the exit condition is to test the
>>> "eth%daddr" env is not NULL. However this creates unnecessary
>>> constrains that those "eth%daddr" env variables must be
>>> sequential even if "ethernet%d" does not start from 0 in the
>>> "/aliases" node. For example, with "/aliases" node below:
>>>
>>> aliases {
>>> ethernet3 = &enet3;
>>> ethernet4 = &enet4;
>>> };
>>>
>>> "ethaddr", "eth1addr", "eth2addr" must exist in order to fix
>>> up ethernet3's MAC address successfully.
>>>
>>> Now we change the loop logic to iterate the properties in the
>>> "/aliases" node. For each property, test if it is in a format
>>> of "ethernet%d", then get its MAC address from corresponding
>>> "eth%daddr" env and fix it up in the dtb.
>>>
>>> Signed-off-by: Bin Meng <bmeng...@gmail.com>
>>
>> Acked-by: Joe Hershberger <joe.hershber...@ni.com>
>
> Thanks! Do you have any comments regarding to "usbethaddr" env that I
> raised here [1]? I originally wanted to remove "usbethaddr" handling
> completely in fdt_fixup_ethernet(), but did not do that when I
> submitted this patch.
>
> [1] http://lists.denx.de/pipermail/u-boot/2015-October/231791.html
My understanding is that we were going to drop the usbethaddr
variables and just use ethaddr.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
