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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
