[U-Boot] [PATCH 2/4] mx6: soc: Add ENET2 support

[Stefano Babic]

Hi Ye,

On 11/02/2015 03:42, Li Ye-B37916 wrote:

>> Checkpatch complains about extra spaces.
> I will fix this problem.
>>> +		mac[3] = value >> 16 ;
>>> +		mac[4] = value >> 8 ;
>>> +		mac[5] = value ;
>>> +	} else {
>>> +		u32 value = readl(&fuse->mac_addr2);
>>> +		mac[0] = value >> 24 ;
>>> +		mac[1] = value >> 16 ;
>>> +		mac[2] = value >> 8 ;
>>> +		mac[3] = value ;
>>> +
>>> +		value = readl(&fuse->mac_addr_high);
>>> +		mac[4] = value >> 24 ;
>>> +		mac[5] = value >> 16 ;
>> Is it desired that the layout is different between the two mac addresses
>> ? As far as I know, MAC_ADDR in fuses is reserved to customers, and it
>> makes sense they have the same layout.
>> Is there some reason (that I do not know, obviously) to have them
>> different ?
> 
> I think the reason is to save one fuse. If the enet2 has same mac fuse layout as enet1, obviously we have to use one more fuse than
> current layout.


>> Additional, the layout is determined by IC, software just follows it. 

Of course, but I have not the fuse map for SX. Does it mean that SX has
3 fuses defined for customer's use ?

Reason is also because you are defined a rule how to use it. In many
systems with more as one ethernet, the rule is defined by the customer,
for example using consecutives MAC addresses starting from the first one
stored in SOC or on another storage. In this case, we have a mix between
independent MAC addresses (it will be if MAC addresses are completely
stored) and a dependency (MSB is in common). I find better if this
hidden rule is better explained, adding comments for that.

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