Dear Prafulla,
In message
you wrote:
>
> I withdraw my NAK for this patch.
> Let's remove mac randomization support for mvgbe driver.
> If needed, for any particular board, it will be addressed separately.
Thanks a lot - highly appreciated.
Best regards,
Wolfgang Denk
--
DENX Software Engi
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, November 17, 2011 1:57 AM
> To: Michael Walle
> Cc: Prafulla Wadaskar; Valentin Longchamp; Siddarth Gore; Simon
> Guinot; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] mvg
Dear Michael Walle,
In message <20162115.0.mich...@walle.cc> you wrote:
>
> > Could you please revise your assessment? I would really appreciate if
> > we could clean this up.
> Regarding Prafulla's NAK?
Yes - I'd really appreciate if Prafulla woudl withdraw his NAK, and
agree on a clea
Hi Wolfgang,
Am Donnerstag 10 November 2011, 12:44:26 schrieb Wolfgang Denk:
> Dear Prafulla,
>
> In message <48935aa530a6457b76b9915a1fe7faf9.squir...@ssl.serverraum.org>
Michael Walle wrote:
> > >> So was there any conclusion, now? Never touch mvgbe.c anymore?
> > >
> > > Let's remove this b
On Thu, Nov 10, 2011 at 12:09:04PM -0500, Mike Frysinger wrote:
> On Thursday 10 November 2011 09:21:53 Simon Guinot wrote:
> > On Thu, Nov 10, 2011 at 01:01:59PM +0100, Wolfgang Denk wrote:
> > > Simon Guinot wrote:
> > > > > > Let's remove this broken code.
> > > > >
> > > > > This is exactly pa
Am Donnerstag 10 November 2011, 15:21:53 schrieb Simon Guinot:
> For this boards a random MAC address is used and the computation is
> performed by the driver mvgbe. If this code is simply removed, the
> network initialization for this boards will break.
Moving this feature into some common code w
On Thursday 10 November 2011 09:21:53 Simon Guinot wrote:
> On Thu, Nov 10, 2011 at 01:01:59PM +0100, Wolfgang Denk wrote:
> > Simon Guinot wrote:
> > > > > Let's remove this broken code.
> > > >
> > > > This is exactly part of this patch ([PATCH] mvgbe: remove setting of
> > > > ethaddr within th
On Thursday 10 November 2011 11:30:13 Valentin Longchamp wrote:
> On 11/10/2011 04:53 PM, Wolfgang Denk wrote:
> > In message <2010142152.gc29...@kw.sim.vm.gnt> you wrote:
> >> I suspect a lot of Marvell boards from being in the same case.
> >
> > Argh... I was not aware that the scope of dama
On 11/10/2011 05:30 PM, Valentin Longchamp wrote:
> On 11/10/2011 04:53 PM, Wolfgang Denk wrote:
>> In message <2010142152.gc29...@kw.sim.vm.gnt> you wrote:
>>>
>>> I suspect a lot of Marvell boards from being in the same case.
>>
>> Argh... I was not aware that the scope of damage already done
On 11/10/2011 04:53 PM, Wolfgang Denk wrote:
> In message <2010142152.gc29...@kw.sim.vm.gnt> you wrote:
>>
>> I suspect a lot of Marvell boards from being in the same case.
>
> Argh... I was not aware that the scope of damage already done was that
> big.
>
On the Keymile boards (for marvell
Dear Simon Guinot,
In message <2010142152.gc29...@kw.sim.vm.gnt> you wrote:
>
> I can't list this boards exactly. For sure, I can say that the
> LaCie boards (netspace_v2 and cie) are concerned.
>
> For this boards a random MAC address is used and the computation is
> performed by the driver
Hi Wolfgang,
On Thu, Nov 10, 2011 at 01:01:59PM +0100, Wolfgang Denk wrote:
> Dear Simon Guinot,
>
> In message <2010110608.gb29...@kw.sim.vm.gnt> you wrote:
> >
> > > > Let's remove this broken code.
> > >
> > > This is exactly part of this patch ([PATCH] mvgbe: remove setting of
> > > eth
Dear Simon Guinot,
In message <2010110608.gb29...@kw.sim.vm.gnt> you wrote:
>
> > > Let's remove this broken code.
> >
> > This is exactly part of this patch ([PATCH] mvgbe: remove setting of
> > ethaddr within the driver). This part, while ACK'ed by Mike, was NAK'ed by
> > Prafulla.
>
> As
Dear Prafulla,
In message <48935aa530a6457b76b9915a1fe7faf9.squir...@ssl.serverraum.org>
Michael Walle wrote:
>
> >> So was there any conclusion, now? Never touch mvgbe.c anymore?
> > Let's remove this broken code.
>
> This is exactly part of this patch ([PATCH] mvgbe: remove setting of
> ethad
Hi Michael,
On Thu, Nov 10, 2011 at 10:15:28AM +0100, Michael Walle wrote:
>
> Hi Wolfgang,
>
> >> So was there any conclusion, now? Never touch mvgbe.c anymore?
> > Let's remove this broken code.
>
> This is exactly part of this patch ([PATCH] mvgbe: remove setting of
> ethaddr within the driv
Hi Wolfgang,
>> So was there any conclusion, now? Never touch mvgbe.c anymore?
> Let's remove this broken code.
This is exactly part of this patch ([PATCH] mvgbe: remove setting of
ethaddr within the driver). This part, while ACK'ed by Mike, was NAK'ed by
Prafulla.
--
Michael
Dear "Michael Walle",
In message you
wrote:
>
> So was there any conclusion, now? Never touch mvgbe.c anymore?
Let's remove this broken code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-8219
>> atm there is the mvgbe driver:
>> - which has a hardcoded mac address (or if enabled, a randomized mac
>> address)
>>and
>> - touches the environment
>
> oh and i've forgot to mention, that the driver is broken for boards with
>
> #define CONFIG_MVGBE_PORTS {0,1}
>
> which is the reason w
Am Mi, 9.11.2011, 00:26 schrieb Michael Walle:
> atm there is the mvgbe driver:
> - which has a hardcoded mac address (or if enabled, a randomized mac
> address)
>and
> - touches the environment
oh and i've forgot to mention, that the driver is broken for boards with
#define CONFIG_MVGBE_P
On Tuesday 08 November 2011 17:45:12 Michael Walle wrote:
> btw only ethaddr is protected and not ethNaddr, which is a bug imho ;)
yeah, it is, but i've ignored it as all my boards have only had 1 eth dev.
feel free to post a patch :).
-mike
signature.asc
Description: This is a digitally signe
Dear Michael Walle,
In message <20090026.09460.mich...@walle.cc> you wrote:
>
> may be possible, but then there is a window of opportunity where the mac is
> already erased but the not yet written with a new one.
Sure. If you look hard enough you will always find a way to brick a
device. A
Am Dienstag 08 November 2011, 23:52:56 schrieb Wolfgang Denk:
> > thanks for the hint, but there is only 512kb flash on this board (with
> > 64k sectors). I don't think there is enough room for a second copy of
> > the environment.
>
> You don't need a separate sector. How bis is your environment
Dear Michael Walle,
In message <20082330.40253.mich...@walle.cc> you wrote:
>
> > There are more clever ways than just to clear the environment. We have
> > "env export" and "env import", so you can create one or more backup
> > copies or user proviles. Instead of clearing the environment, yo
Am Dienstag 08 November 2011, 21:49:49 schrieb Mike Frysinger:
> On Tuesday 08 November 2011 12:34:17 Michael Walle wrote:
> > Am Di, 8.11.2011, 16:17 schrieb Wolfgang Denk:
> > > Michael Walle wrote:
> > >> >> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
> > >> >
> > >> > NAK to this. board config
Am Dienstag 08 November 2011, 20:28:19 schrieb Wolfgang Denk:
> Dear "Michael Walle",
>
> In message <45fd92b472c944e2cb9ebb409488ccfc.squir...@ssl.serverraum.org>
you wrote:
> > If someone will mess up the environment, it is possible to clear it by
> > holding a button upon powerup. Atm i have t
On Tuesday 08 November 2011 12:34:17 Michael Walle wrote:
> Am Di, 8.11.2011, 16:17 schrieb Wolfgang Denk:
> > Michael Walle wrote:
> >> >> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
> >> >
> >> > NAK to this. board configs are not allow to hardcode MACs.
> >>
> >> mh, so why is there a CONFIG_E
Dear "Michael Walle",
In message <45fd92b472c944e2cb9ebb409488ccfc.squir...@ssl.serverraum.org> you
wrote:
>
> If someone will mess up the environment, it is possible to clear it by
> holding a button upon powerup. Atm i have the CONFIG_ETH_ADDR set to a
> default MAC address to be able to use t
Hi Wolfgang, Hi Mike,
Am Di, 8.11.2011, 16:17 schrieb Wolfgang Denk:
> Dear "Michael Walle",
>
> In message <89e599b8867346f857ae2f132e9717a3.squir...@ssl.serverraum.org>
> you wrote:
>>
>> >> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
>> >
>> > NAK to this. board configs are not allow to hardcod
Dear "Michael Walle",
In message <89e599b8867346f857ae2f132e9717a3.squir...@ssl.serverraum.org> you
wrote:
>
> >> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
> >
> > NAK to this. board configs are not allow to hardcode MACs.
> mh, so why is there a CONFIG_ETH_ADDR macro? is it deprecated?
> READM
Dear Mike Frysinger,
In message <20080858.25678.vap...@gentoo.org> you wrote:
>
> > 3. mac randomization should be enabled by
> > CONFIG_SYS_LOCAL_MAC_RANDOMIZATION macro 4. For mvgbe uses it should be
> > enabled by default in include/configs/mv-common.h. 5. for corner case like
> > edminiv2,
On Tuesday 08 November 2011 08:45:27 Michael Walle wrote:
> Am Di, 8.11.2011, 14:57 schrieb Mike Frysinger:
> > On Monday 07 November 2011 17:08:09 Michael Walle wrote:
> >> --- a/include/configs/edminiv2.h
> >> +++ b/include/configs/edminiv2.h
> >>
> >> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
Am Di, 8.11.2011, 14:57 schrieb Mike Frysinger:
> On Monday 07 November 2011 17:08:09 Michael Walle wrote:
>> drivers/net/mvgbe.c| 23 ---
>
> ACK to the changes to this file
>
>> --- a/include/configs/edminiv2.h
>> +++ b/include/configs/edminiv2.h
>>
>> +#define CONFI
On Tuesday 08 November 2011 02:18:20 Prafulla Wadaskar wrote:
> Here are my suggestions-
> 1. commond/random_mac.c should be added
> 2. call back function should be provided to generate random number, those
> should be defined in arch specific code (for Kirkwood arch-kirkwood/cpu.c)
> 3. mac random
On Monday 07 November 2011 17:08:09 Michael Walle wrote:
> drivers/net/mvgbe.c| 23 ---
ACK to the changes to this file
> --- a/include/configs/edminiv2.h
> +++ b/include/configs/edminiv2.h
>
> +#define CONFIG_ETH_ADDR 02:50:43:00:00:01
NAK to this. board configs a
> -Original Message-
> From: Michael Walle [mailto:mich...@walle.cc]
> Sent: Tuesday, November 08, 2011 3:38 AM
> To: u-boot@lists.denx.de
> Cc: Michael Walle; Mike Frysinger; Valentin Longchamp; Eric
> Cooper; Jason Cooper; Siddarth Gore; Albert ARIBAUD; Prafulla
> Wadaskar; Simon Guinot
A network driver should not touch the environment at all. This patch fixes
this behaviour by removing the code for setting a default/randomized MAC
address.
Instead a board should either set CONFIG_ETHADDR, CONFIG_ETH1ADDR etc. or
use some specific code within the board files, eg. if randomization
36 matches
Mail list logo
