[U-Boot] [PATCH 2/2] mvgbe: fix network device indices

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 05/11/2011 00:06, Mike Frysinger a ?crit :
> On Friday 04 November 2011 02:29:24 Prafulla Wadaskar wrote:
>> Mike Frysinger:
>>> On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
>>>> Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike Frysinger:
>>>>> On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
>>>>>> --- a/drivers/net/mvgbe.c
>>>>>> +++ b/drivers/net/mvgbe.c
>>>>>>
>>>>>> +		/* Extract the MAC address from the environment */
>>>>>> +		while (!eth_getenv_enetaddr_by_index("eth", dev-index,
>>>>>> +					dev->enetaddr)) {
>>>>>>
>>>>>>   			/* Generate Private MAC addr if not set */
>>>>>>   			dev->enetaddr[0] = 0x02;
>>>>>>   			dev->enetaddr[1] = 0x50;
>>>>>
>>>>> this is wrong.  net drivers should not be touching the env
>>>>> at all.  please fix your driver to not do that first.
>>>>
>>>> i guess this whole mac randomization/generation code belongs to board
>>>> specific files.
>>>
>>> correct
>>
>> We can move mac randomization code to the board specific files, but it will
>> be needed for each board and there will be code duplication.
>
> there's two issues here.  (1) no net driver should touch the env.  this is why
> we have the dev->enetaddr field in the first place.  (2) drivers should be
> seeding dev->enetaddr with values from storage directly related to it.  so for
> parts that have dedicated EEPROM interfaces, reading the MAC out of that
> storage makes sense.  if no storage like that exists, then it is up to the
> board to figure out where to find the address.
>
> that means this could should be moved to the boards file.
>
>> How about supporting standalone mac randomization feature?
>
> i think Wolfgang would be opposed to that.  mac randomization should not be
> the first line of defense.  your board is supposed to be managing this sanely.
> from the mvgbe code, it seems that this is not the case and these boards are a
> bit insane.

Granted, MAC randomization as a feature -- i.e., choosing to use a 
random MAC *instead* of any other way -- would be Bad(tm).

But what about MAC randomization as a function provided by the SoC level 
to board MAC init code that wants to use it? For instance, a weak MAC 
setup function provided by the SoC level, and the board level would use 
it or provide its own.

> -mike

Amicalement,
-- 
Albert.