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@heimpold.de Cc: Stefano Babic sbabic@denx.de Cc: Marek Vasut marex@denx.de CC: Fabio Estevam fabio.estevam@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