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

[Prafulla Wadaskar]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.u.boot at aribaud.net]
> Sent: Saturday, November 05, 2011 3:24 PM
> To: Mike Frysinger
> Cc: Prafulla Wadaskar; u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH 2/2] mvgbe: fix network device
> indices
> 
> 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.

I ack for this method

Regards..
Prafulla . .