On Fri, Oct 30, 2015 at 10:16:49AM +0800, Bin Meng wrote:
Hi Joe,
On Fri, Oct 30, 2015 at 3:38 AM, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Bin,
On Wed, Oct 28, 2015 at 8:40 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Joe,
On Thu, Oct 29, 2015 at 4:52 AM, Joe Hershberger joe.hershberger@gmail.com wrote:
Hi Bin,
On Tue, Oct 27, 2015 at 11:10 AM, Bin Meng bmeng.cn@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.cn@gmail.com
Acked-by: Joe Hershberger joe.hershberger@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
I'm in agreement with you. See here: http://lists.denx.de/pipermail/u-boot/2015-July/218601.html
It would be great if you completely remove it.
Good. I will prepare a patch to remove "usbethaddr" in fdt_fixup_ethernet().
So long as you don't break the boards that need it :)