On 11/22/2017 03:52 AM, Prabhakar Kushwaha wrote: > >> -----Original Message----- >> From: York Sun >> Sent: Tuesday, November 21, 2017 10:52 PM >> To: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; u- >> b...@lists.denx.de >> Subject: Re: [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env >> variable serially >> >> On 11/21/2017 08:26 AM, Prabhakar Kushwaha wrote: >>> Current implementation of MAC address fix-up of device tree uses >>> tailing number behind "ethernet" found in "/aliases". It is not >>> necessary for trailing number of “ethernet” to be sequential. There >>> can be hole in between or any node disabled. >>> >>> So provide support device tree fix-up of “ethernent” node with MAC >>> addresses fetched sequentially from environment variables. >> >> My understanding is current implementation matches the trailing number >> behind "ethernet" found in "/aliases" with environmental variables >> ethNaddr (where N is 1, 2, 3, ... or absent). This doesn't require >> "ethernet" nodes or ethNaddr variables to be consecutive. >> >> From your change, I understand you are trying to apply consecutive >> ethNaddr variables to "ethernet" nodes in the order they appear in >> device tree. >> >> You didn't explain what benefit you get from this new scheme, or what >> problem you are trying to solve. >> >> My understanding is you have device tree with some "ethernet" nodes >> disabled (or with gap in the numbering). You also have a pool of MAC >> addresses in the form of consecutive ethNaddr variables. You goal is to >> assign these ethNaddr to "ethernet" nodes in the order they appear in >> the device tree. Do I understand you correctly? > > Yes this understanding is correct. > I am parsing "ethernet" node from device tree and fixing up ethNaddr > sequentially. > > >> >> Is it possible to address this issue from another angle? How about >> setting ethNaddr variables in U-Boot according to the SerDes protocol? >> You may have explored this path already. Let me know why this doesn't work. > > Yes, analyzed this path and figured out following 2 changes in u-boot > > A) I2C EEPROM: Here MAC number has to be read sequentially from EEPROM and > they have to save as ethNaddr. here N is MAC number as per SerDes > MAC number will be saved in ethaddr, eth1addr, eth2addr, eth3addr, > eth10addr depending upon SerDes protocol > > B) net/eth_legacy.c: eth_initialize() --> eth_write_hwaddr > here each Ethernet driver read ethNaddr. Here N represents eth_device-> > index. > Please note eth_device->index in under control of Ethernet subsystem and > incremented automatically per Ethernet device. > > for a Ethernet device which require eth9addr (updated as part of A). It must > have 10 ethernet device before it to get correct eth9addr. > Hence a mapping required from eth_device->index to MAC number. I wanted to > avoid "B" to make sure Ethernet device initialization path remain unchanged. > > Hence chosen to update fdt_support.c >
Thanks for the explanation. I will leave the decision to Simon Glass. In the meantime, maybe you can rephrase the commit message to make it more clear. York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot