[U-Boot] [PATCH] arm: mxs: fix mac address of second interface

[Michael Heimpold]

Hi Stefano,

Am Sonntag, 23. August 2015, 17:38:05 schrieb Stefano Babic:
> Hi Michael,
> 
> On 16/08/2015 00:16, Michael Heimpold wrote:
> > In the rare case that an overflow occurs, propagate it.
> > 
> > Signed-off-by: Michael Heimpold <mhei at heimpold.de>
> > Cc: Stefano Babic <sbabic at denx.de>
> > Cc: Marek Vasut <marex at denx.de>
> > CC: Fabio Estevam <fabio.estevam at freescale.com>
> > ---
> >  arch/arm/cpu/arm926ejs/mxs/mxs.c |   12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c b/arch/arm/cpu/arm926ejs/mxs/mxs.c
> > index b1d8721..42057ad 100644
> > --- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
> > +++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
> > @@ -238,11 +238,19 @@ int cpu_eth_init(bd_t *bis)
> >  
> >  __weak void mx28_adjust_mac(int dev_id, unsigned char *mac)
> >  {
> > +	uint32_t data;
> > +
> >  	mac[0] = 0x00;
> >  	mac[1] = 0x04; /* Use FSL vendor MAC address by default */
> >  
> > -	if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
> > -		mac[5] += 1;
> > +	if (dev_id == 1) { /* Let MAC1 be MAC0 + 1 by default */
> > +		data = (mac[3] << 16) | (mac[4] << 8) | mac[5];
> > +		data++;
> > +
> > +		mac[3] = (data >> 16) & 0xff;
> > +		mac[4] = (data >> 8) & 0xff;
> > +		mac[5] = data & 0xff;
> > +	}
> >  }
> >  
> 
> Even if on a theoretical point of view this is correct, I guess there is
> something fundamentally wrong.
> 
> We cannot set any MAC address we want. MAC addresses must be bought,
> even by the manufacturer (Freescale) if it wants to deliver SOC with
> preinstalled MAC addresses. In most cases but not all, the user of the
> SOC wants to have his Vendor-id, and he buys a range of addresses. If
> the target has two ethernet, he will reserve two addresses for each
> board and it is common practise to have two consecutive addresses,
> without any roll up - this is avoided by the logistic assigning a even
> number of addresses to the board.
> 

The simplest approach for assigning MAC addresses to a board is IMO
that the board gets the first free one or -when the board has two ethernets-
the first two free (consecutive) addresses of the bought address pool
during manufacturing process. Without any reservation/pre-allocation, simply
first come first served.
Thus there is no guarantee in case of a two-ethernet-board that the first
address is an even one, because you don't know the order of manufacturing
of products which require only one and/or which require two addresses.
Using this very simple algorithm does not prevent such an overflow and
when the board/devices has a label with the two printed addresses the
second one does not match. So this is/was my real case.
I totally agree that there might be smarter algorithms and/or better
best practises to assign MAC addresses; and I really don't know,
how FSL/Denx/... handle this in practise.
I can only tell for the company I'm working for or I worked for...

> The case you want to fix should never happen - not due to the code, but
> how addresses are managed in practise. And delivering a board with two
> very different addresses, as in case of an overflow, can be also seen
> weird by the customer.

Maybe. More important to the customer would be that in case of rollover
the second address might be already used (legally) by another device (at least
when the manufacturing process is not as smart as you assumed).
Yes, I know that this is even more theoretical that exactly this customer has exactly
this board in exactly this very same network :-)

> 
> Is this a real case ?
> 
> Best regards,
> Stefano Babic
> 

Best regards,
Michael Heimpold