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

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

Is this a real case ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================