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

[Prabhakar Kushwaha]

> -----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  

-pk









> 
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>
> > ---
> >  README               | 10 ++++++++++
> >  common/fdt_support.c | 25 +++++++++++++++++++++----
> >  2 files changed, 31 insertions(+), 4 deletions(-)
> >
> > diff --git a/README b/README
> > index 7a4f342..640b310 100644
> > --- a/README
> > +++ b/README
> > @@ -1603,6 +1603,16 @@ The following options need to be configured:
> >
> >  		See doc/README.link-local for more information.
> >
> > + - MAC address from environment variables
> > +
> > +		FDT_SEQ_MACADDR_FROM_ENV
> 
> Why not create a Kconfig option?
> 
> York