> -----Original Message----- > From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] > Sent: Saturday, November 05, 2011 3:24 PM > To: Mike Frysinger > Cc: Prafulla Wadaskar; u-boot@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 . . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot