[U-Boot] [PATCH 1/3] common: Fix-up MAC addr in dts by fetching env variable serially

[York Sun]

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.kushwaha at nxp.com>; u-
>> boot at 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