mvgbe: fix network device indices
Subsystems (2)
PATCH 1/1 mvgbe: fix network device indices
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environmen varibale ethaddr.
--- drivers/net/mvgbe.c | 13 +++++++------ include/net.h | 12 ++++++++++++ net/eth.c | 8 ++++++++ 3 files changed, 27 insertions(+), 6 deletions(-)
drivers/net/mvgbe.c +7 -6
@@ -645,7 +645,7 @@ int mvgbe_initialize(bd_t *bis)struct mvgbe_device *dmvgbe;struct eth_device *dev;int devnum; -char *s; +int eth_idx =0 ;u8 used_ports[MAX_MVGBE_DEVS ] =CONFIG_MVGBE_PORTS ;for (devnum =0 ; devnum <MAX_MVGBE_DEVS ; devnum++) {
@@ -700,16 +700,13 @@ error1:/* must be less than NAMESIZE (16) */ sprintf (dev->name,"egiga%d" , devnum); -/* Extract the MAC address from the environment */ switch (devnum) {case 0 : dmvgbe->regs = (void *)MVGBE0_BASE ; - s ="ethaddr" ;break ;#if defined(MVGBE1_BASE )case 1 : dmvgbe->regs = (void *)MVGBE1_BASE ; - s ="eth1addr" ;break ;#endif default :/* this should never happen */
@@ -718,7 +715,9 @@ error1:return -1 ; } -while (!eth_getenv_enetaddr (s, dev->enetaddr)) { +/* Extract the MAC address from the environment */ +while (!eth_getenv_enetaddr_by_index ("eth" , eth_idx, + dev->enetaddr)) {/* Generate Private MAC addr if not set */ dev->enetaddr[0 ] =0x02 ; dev->enetaddr[1 ] =0x50 ;
@@ -734,7 +733,7 @@ error1: dev->enetaddr[4 ] =get_random_hex (); dev->enetaddr[5 ] =get_random_hex ();#endif -eth_setenv_enetaddr (s, dev->enetaddr); +eth_setenv_enetaddr_by_index ("eth" , eth_idx, dev->enetaddr); } dev->init = (void *)mvgbe_init;
@@ -745,6 +744,8 @@ error1:eth_register (dev); + eth_idx++; +#if defined(CONFIG_MII ) || defined(CONFIG_CMD_MII )miiphy_register (dev->name, smi_reg_read, smi_reg_write);/* Set phy address of the port */
include/net.h +12 -0
@@ -103,6 +103,18 @@ extern int eth_setenv_enetaddr(char *name, const uchar *enetaddr);extern int eth_getenv_enetaddr_by_index (const char *base_name,int index,uchar *enetaddr); +/* +* Set the hardware address for an ethernet interface. +* Args: +* base_name - base name for device (normally "eth") +* index - device index number (0 for first) +* enetaddr - returns 6 byte hardware address +* Returns: +* Return true if the environment varibable was set successfully. +*/ +extern int eth_setenv_enetaddr_by_index (const char *base_name,int index, +const uchar *enetaddr); +extern int usb_eth_initialize (bd_t *bi);extern int eth_init (bd_t *bis);/* Initialize the device */ extern int eth_send (volatile void *packet,int length);/* Send a packet */
net/eth.c +8 -0
@@ -62,6 +62,14 @@ int eth_getenv_enetaddr_by_index(const char *base_name, int index,return eth_getenv_enetaddr (enetvar, enetaddr); } +int eth_setenv_enetaddr_by_index (const char *base_name,int index, +const uchar *enetaddr) +{ +char enetvar[32 ]; +sprintf (enetvar, index ?"%s%daddr" :"%saddr" , base_name, index); +return eth_setenv_enetaddr (enetvar, enetaddr); +} +static int eth_mac_skip (int index) {char enetvar[15 ];
Signature · 1 line
1.7.2.5
PATCH 1/1 mvgbe: fix network device indices
Quoted 9 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indices
Quoted 5 lines
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environmen varibale
ethaddr.
So if there is only one eth port available, the associated environment variable should be ethaddr, this is understood. Is there any issue with this?
Then I have anther question in my mind-
Why not we name eth0addr for environment variable associated with egiga0 to maintain consistency with naming and used ports?
Regards..
Prafulla . .
PATCH 1/1 mvgbe: fix network device indices
Am Fr, 7.10.2011, 10:26 schrieb Prafulla Wadaskar:
Quoted 13 lines
Quoted 7 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indicesQuoted 5 lines
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environmen varibale
ethaddr.
Quoted 3 lines
So if there is only one eth port available, the associated environment variable should be ethaddr, this is understood.
Is there any issue with this?
Are you asking me or the list? (if the question was for me, remember that there might be _only_ the egiga1 device.)
Quoted 3 lines
Then I have anther question in my mind-
Why not we name eth0addr for environment variable associated with egiga0 to maintain consistency with naming and used ports?
If i get it right, there is another problem with setting the environment variable from the driver itself.
eth_register() and eth_init() using an own index to enumerate the devices. Eg. if an e1000 is registered before the the associated environment variable would be eth1addr for the first mvgbe device and eth2addr for the second.
This patch only fixes the case where no other network device is registered. (The current behaviour just works with egiga0 being the only or the first and egiga1 being the second device).
Signature · 1 line
Michael
PATCH 1/1 mvgbe: fix network device indices
Am Freitag 07 Oktober 2011, 12:48:40 schrieb Michael Walle:
Quoted 28 lines
Am Fr, 7.10.2011, 10:26 schrieb Prafulla Wadaskar:
Quoted 13 lines
Quoted 7 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indicesQuoted 5 lines
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environmen varibale
ethaddr.Quoted 3 lines
So if there is only one eth port available, the associated environment variable should be ethaddr, this is understood.
Is there any issue with this?Are you asking me or the list? (if the question was for me, remember that there might be _only_ the egiga1 device.)
Quoted 3 lines
Then I have anther question in my mind-
Why not we name eth0addr for environment variable associated with egiga0 to maintain consistency with naming and used ports?If i get it right, there is another problem with setting the environment variable from the driver itself.
Quoted 8 lines
eth_register()andeth_init()using an own index to enumerate the devices. Eg. if an e1000 is registered before the the associated environment variable would be eth1addr for the first mvgbe device and eth2addr for the second.This patch only fixes the case where no other network device is registered. (The current behaviour just works with egiga0 being the only or the first and egiga1 being the second device).
ping :)
Signature · 1 line
Michael
PATCH 1/1 mvgbe: fix network device indices
In reply to Michael Wallenet/eth.c int eth_getenv_enetaddr_by_index(const char *base_name, int index, · line 71
Quoted 10 lines · On Thursday 06 October 2011 18:23:22 Michael Walle wrote:
net/eth.c +7
-0+int eth_setenv_enetaddr_by_index (const char *base_name,int index, +const uchar *enetaddr) +{ +char enetvar[32 ]; +sprintf (enetvar, index ?"%s%daddr" :"%saddr" , base_name, index); +return eth_setenv_enetaddr (enetvar, enetaddr); +}
please unify the duplicate logic coming from eth_getenv_enetaddr_by_index in a new local static function
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111007/9420fe8d/attachment.pgp
PATCH 1/1 mvgbe: fix network device indices
In reply to Michael WalleQuoted 9 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indices
Quoted 5 lines
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environment varibale
ethaddr.
Hi
If I understood it correctly,
In current implementation, if only egiga1 device is enabled on the board, then it will assign MAC address associated with environment variable "ethaddr".
This patch will make environment variable "egiga1" available in such case. Right?
If so, then this is not the case with only mvgbe, it is applicable for all network drivers.
I think this is okay, are there any issues following this standard structure at your end?
Regards..
Prafulla . . .
PATCH 1/1 mvgbe: fix network device indices
Am Freitag 21 Oktober 2011, 10:09:15 schrieben Sie:
Quoted 13 lines
Quoted 7 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indicesQuoted 5 lines
Don't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0 and therefore the MAC address is set with the environment varibale
ethaddr.
Quoted 6 lines
Hi
If I understood it correctly,
In current implementation, if only egiga1 device is enabled on the board, then it will assign MAC address associated with environment variable "ethaddr".
yes but the current mvgbe driver will check eth1addr and set it to a random value if not set.
Quoted 2 lines
This patch will make environment variable "egiga1" available in such case. Right?
mh? This patch will use the same enumeration as the net/eth.c code in eth_initialize(). At least if there is no other ethernet driver than mvgbe. So ethaddr is set to a random value instead of eth1addr, which eth_initialize() then use the set the mac address.
Quoted 2 lines
If so, then this is not the case with only mvgbe, it is applicable for all network drivers.
yeah other drivers also set eth(N)addr sometimes, which suffers from the same problem. maybe a driver could provide some callback to initialize a macaddress or eth_register returns the device index which in turn could be used to get the proper ethNaddr environment variable.
Signature · 1 line
Michael
PATCH 1/1 mvgbe: fix network device indices
Quoted 31 lines
-----Original Message-----
From: Michael Walle [mailto:michael at walle.cc]
Sent: Wednesday, October 26, 2011 2:41 AM
To: Prafulla Wadaskar
Cc: u-boot at lists.denx.de; Mike Frysinger
Subject: Re: [U-Boot] [PATCH] mvgbe: fix network device indicesAm Freitag 21 Oktober 2011, 10:09:15 schrieben Sie:
Quoted 2 lines
Quoted 2 lines
-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
Quoted 6 lines
Quoted 6 lines
On Behalf Of Michael Walle
Sent: Friday, October 07, 2011 3:53 AM
To: u-boot at lists.denx.de
Subject: [U-Boot] [PATCH] mvgbe: fix network device indicesDon't assume that the MAC address of egiga0 rsp. egiga1 is
ethaddr rsp.
Quoted 1 line
Quoted 1 line
eth1addr. If there is only a egiga1 device, u-boot will
enumerate it as
Quoted 1 line
Quoted 1 line
device 0 and therefore the MAC address is set with the
environment
Quoted 7 lines
Quoted 2 lines
varibale
ethaddr.Hi
If I understood it correctly,
In current implementation, if only egiga1 device is enabled
Quoted 7 lines
on the board,
Quoted 1 line
then it will assign MAC address associated with environment
variable
Quoted 1 line
"ethaddr".
yes but the current mvgbe driver will check eth1addr and set it to a random
value if not set.
Yes, but this may be avoided by defining CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION as done for edminiv2 board.
Quoted 13 lines
Quoted 2 lines
This patch will make environment variable "egiga1" available
in such case.
Quoted 1 line
Right?
mh? This patch will use the same enumeration as the
net/eth.ccode ineth_initialize(). At least if there is no other ethernet driver than mvgbe.
So ethaddr is set to a random value instead of eth1addr, whicheth_initialize()then use the set the mac address.Quoted 1 line
If so, then this is not the case with only mvgbe, it is
applicable for all
Quoted 8 lines
Quoted 1 line
network drivers.
yeah other drivers also set eth(N)addr sometimes, which suffers from the same
problem. maybe a driver could provide some callback to initialize a macaddress
oreth_registerreturns the device index which in turn could be used to get
the proper ethNaddr environment variable.
I think right place to provide solution for this problem is net/eth.c.
The suggested change is logical but doing this will affect all u-boot users. May be some more opinion on this will be helpful.
Regards..
Prafulla . . .
Quoted 3 lines
--
Michael
PATCH 1/1 mvgbe: fix network device indices
Am Do, 27.10.2011, 11:12 schrieb Prafulla Wadaskar:
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
If I understood it correctly,
In current implementation, if only egiga1 device is enabledon the board,
Quoted 1 line
then it will assign MAC address associated with environment
Quoted 8 lines
Quoted 5 lines
variable
Quoted 1 line
"ethaddr".
yes but the current mvgbe driver will check eth1addr and set it to a random
value if not set.Yes, but this may be avoided by defining
CONFIG_SKIP_LOCAL_MAC_RANDOMIZATIONas done for edminiv2 board.
Ok, but that is not my problem ;) And even if this macro is set, the wrong environment variable will still be set (in this case not a randomized mac address, but :00:00:<devnum> suffix).
Quoted 21 lines
Quoted 12 lines
Quoted 1 line
This patch will make environment variable "egiga1" available
in such case.
Quoted 1 line
Right?
mh? This patch will use the same enumeration as the
net/eth.ccode ineth_initialize(). At least if there is no other ethernet driver than mvgbe.
So ethaddr is set to a random value instead of eth1addr, whicheth_initialize()then use the set the mac address.Quoted 1 line
If so, then this is not the case with only mvgbe, it is
applicable for all
Quoted 8 lines
Quoted 1 line
network drivers.
yeah other drivers also set eth(N)addr sometimes, which suffers from the same
problem. maybe a driver could provide some callback to initialize a macaddress
oreth_registerreturns the device index which in turn could be used to get
the proper ethNaddr environment variable.
Quoted 3 lines
I think right place to provide solution for this problem is
net/eth.c. The suggested change is logical but doing this will affect all u-boot users. May be some more opinion on this will be helpful.
ok, so the second option still applies, that is eth_register() returns a device index. the current eth_register always returns zero, in fact all drivers in the uboot source don't check the return code. so here we could return the device index.
@wolfgang: any opinion on that? or any other idea how to pass the ethernet device number to a network driver?
Signature · 1 line
Michael
cover improve ethernet device index handling
In reply to Michael WalleThis patchset introduces a new element "index" within the eth_device structure, which is populated by eth_register(). The second patch uses this element to get the right name of the environment variable for the ethernet hardware address.
PATCH 1/2 net: introduce per device index
In reply to Michael WalleInstead of counting the device index everytime a functions needs it, store it in the eth_device struct. eth_register() keeps track of the indices and updates the device's index number. This simplifies some functions in net/eth.c.
Additionally, a network driver can now query its index, eg. to get the correct environment ethaddr name.
--- include/net.h | 1 + net/eth.c | 41 ++++++++++++----------------------------- 2 files changed, 13 insertions(+), 29 deletions(-)
include/net.h +1 -0
@@ -89,6 +89,7 @@ struct eth_device {#endif int (*write_hwaddr) (struct eth_device *);struct eth_device *next; +int index;void *priv; };
net/eth.c +12 -29
123 lines not on this page · raw message
Signature · 1 line
1.7.2.5
PATCH 1/2 net: introduce per device index
Am Donnerstag 27 Oktober 2011, 23:31:35 schrieb Michael Walle:
Quoted 11 lines
Instead of counting the device index everytime a functions needs it, store it in the
eth_devicestruct.eth_register()keeps track of the indices and updates the device's index number. This simplifies some functions innet/eth.c.Additionally, a network driver can now query its index, eg. to get the correct environment ethaddr name.
Signed-off-by Michael Walle <[email protected]>Cc Prafulla Wadaskar <[email protected]>Cc Mike Frysinger <[email protected]>
sorry mike, i'll fix this for v2 ;)
Signature · 1 line
Michael
PATCH 1/2 net: introduce per device index
In reply to Michael WalleAm Do, 27.10.2011, 22:31 schrieb Michael Walle:
Quoted 7 lines
Instead of counting the device index everytime a functions needs it, store it in the
eth_devicestruct.eth_register()keeps track of the indices and updates the device's index number. This simplifies some functions innet/eth.c.Additionally, a network driver can now query its index, eg. to get the correct environment ethaddr name.
Ping, anyone?
Quoted 163 lines
Signed-off-by Michael Walle <[email protected]>Cc Prafulla Wadaskar <[email protected]>Cc Mike Frysinger <[email protected]>Cc Wolfgang Denk <[email protected]>--- include/net.h | 1 + net/eth.c | 41 ++++++++++++----------------------------- 2 files changed, 13 insertions(+), 29 deletions(-)include/net.h +1
-0@@ -89,6 +89,7 @@ struct eth_device {#endif int (*write_hwaddr) (struct eth_device *);struct eth_device *next; +int index;void *priv; };net/eth.c +0
-1@@ -127,7 +127,6 @@ struct eth_device *eth_get_dev_by_name(const char *devname)struct eth_device *eth_get_dev_by_index (int index) {struct eth_device *dev, *target_dev; -int idx =0 ;if (!eth_devices)net/eth.c +12
-29return NULL ;@@ -135,12 +134,11 @@ struct eth_device *eth_get_dev_by_index(int index) dev = eth_devices; target_dev =NULL ;do { -if (idx == index) { +if (dev->index == index) { target_dev = dev;break ; } dev = dev->next; - idx++; }while (dev != eth_devices);return target_dev;@@ -148,24 +146,11 @@ struct eth_device *eth_get_dev_by_index(int index)int eth_get_dev_index (void ) { -struct eth_device *dev; -int num =0 ; - -if (!eth_devices) { -return (-1 ); - } - -for (dev = eth_devices; dev; dev = dev->next) { -if (dev == eth_current) -break ; - ++num; - } - -if (dev) { -return (num); +if (!eth_current) { +return -1 ; } -return (0 ); +return eth_current->index; }static void eth_current_changed (void )@@ -219,6 +204,7 @@ int eth_write_hwaddr(struct eth_device *dev, constchar *base_name, int eth_register(struct eth_device *dev) { struct eth_device *d; +static int index =0 ;assert (strlen (dev->name) <NAMESIZE );@@ -233,14 +219,14 @@ int eth_register(struct eth_device *dev) dev->state =ETH_STATE_INIT ; dev->next = eth_devices; + dev->index = index++;return 0 ; }int eth_initialize (bd_t *bis) { -int eth_number =0 ; - +int num_devices =0 ; eth_devices =NULL ; eth_current =NULL ;@@ -281,7 +267,7 @@ int eth_initialize(bd_t *bis)show_boot_progress (65 ); do { - if (eth_number) + if (dev->index) puts (", "); printf("%s", dev->name);@@ -294,18 +280,18 @@ int eth_initialize(bd_t *bis)if (strchr (dev->name,' ' ))puts ("\nWarning: eth device name has a space!\n" ); -if (eth_write_hwaddr (dev,"eth" , eth_number)) +if (eth_write_hwaddr (dev,"eth" , dev->index))puts ("\nWarning: failed to set MAC address\n" ); - eth_number++; dev = dev->next; + num_devices++; }while (dev != eth_devices);eth_current_changed ();putc ('\n' ); } -return eth_number; +return num_devices; }#ifdef CONFIG_MCAST_TFTP @@ -356,7 +342,6 @@ u32 ether_crc (size_t len, unsigned char const *p)int eth_init (bd_t *bis) { -int eth_number;struct eth_device *old_current, *dev;if (!eth_current) {@@ -365,16 +350,14 @@ int eth_init(bd_t *bis) }/* Sync environment with network devices */ - eth_number =0 ; dev = eth_devices;do {uchar env_enetaddr[6 ]; -if (eth_getenv_enetaddr_by_index ("eth" , eth_number, +if (eth_getenv_enetaddr_by_index ("eth" , dev->index, env_enetaddr))memcpy (dev->enetaddr, env_enetaddr,6 ); - ++eth_number; dev = dev->next; }while (dev != eth_devices); --1.7.2.5
PATCH 1/2 net: introduce per device index
Quoted 16 lines
-----Original Message-----
From: Michael Walle [mailto:michael at walle.cc]
Sent: Thursday, November 03, 2011 4:54 PM
To: Michael Walle
Cc: u-boot at lists.denx.de; Prafulla Wadaskar; Mike Frysinger; Wolfgang Denk; Michael Walle
Subject: Re: [PATCH 1/2] net: introduce per device indexAm Do, 27.10.2011, 22:31 schrieb Michael Walle:
Quoted 1 line
Instead of counting the device index everytime a functions
needs it, store
Quoted 1 line
it in the
eth_devicestruct.eth_register()keeps track ofthe indices and
Quoted 1 line
updates the device's index number. This simplifies some
Quoted 16 lines
functions in
Quoted 3 lines
net/eth.c.Additionally, a network driver can now query its index, eg.
to get the
Quoted 1 line
correct environment ethaddr name.
Ping, anyone?
Quoted 7 lines
Signed-off-by Michael Walle <[email protected]>Cc Prafulla Wadaskar <[email protected]>Cc Mike Frysinger <[email protected]>Cc Wolfgang Denk <[email protected]>--- include/net.h | 1 + net/eth.c | 41 ++++++++++++---------------------------
These patches are for u-boot-net.git.
Copying Ben on this.
Regards..
Prafulla . .
PATCH 1/2 net: introduce per device index
Dear Prafulla Wadaskar,
Quoted 3 lines · In message <[email protected]>…
These patches are for u-boot-net.git.
Copying Ben on this.
Ben has resigned long ago. We're currently without Net custodian (any volunteers out there??) so I will have to pick that up - when time comes.
The patch was submitted after close of trhe merge window, so it is low priority for now.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Minds are like parachutes - they only function when open.
PATCH 1/2 net: introduce per device index
In reply to Michael Walle-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111103/4203f9b2/attachment.pgp
PATCH 2/2 mvgbe: fix network device indices
In reply to Michael WalleDon't assume that the MAC address of egiga0 rsp. egiga1 is ethaddr rsp. eth1addr. If there is only a egiga1 device, u-boot will enumerate it as device 0. Instead use the correct index number stored within the eth_device structure.
--- drivers/net/mvgbe.c | 27 +++++++++++++-------------- include/net.h | 12 ++++++++++++ net/eth.c | 17 ++++++++++++++++- 3 files changed, 41 insertions(+), 15 deletions(-)
drivers/net/mvgbe.c +13 -14
@@ -645,7 +645,6 @@ int mvgbe_initialize(bd_t *bis)struct mvgbe_device *dmvgbe;struct eth_device *dev;int devnum; -char *s;u8 used_ports[MAX_MVGBE_DEVS ] =CONFIG_MVGBE_PORTS ;for (devnum =0 ; devnum <MAX_MVGBE_DEVS ; devnum++) {
@@ -700,16 +699,13 @@ error1:/* must be less than NAMESIZE (16) */ sprintf (dev->name,"egiga%d" , devnum); -/* Extract the MAC address from the environment */ switch (devnum) {case 0 : dmvgbe->regs = (void *)MVGBE0_BASE ; - s ="ethaddr" ;break ;#if defined(MVGBE1_BASE )case 1 : dmvgbe->regs = (void *)MVGBE1_BASE ; - s ="eth1addr" ;break ;#endif default :/* this should never happen */
@@ -718,7 +714,17 @@ error1:return -1 ; } -while (!eth_getenv_enetaddr (s, dev->enetaddr)) { + dev->init = (void *)mvgbe_init; + dev->halt = (void *)mvgbe_halt; + dev->send = (void *)mvgbe_send; + dev->recv = (void *)mvgbe_recv; + dev->write_hwaddr = (void *)mvgbe_write_hwaddr; + +eth_register (dev); + +/* 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 ;
@@ -734,17 +740,10 @@ error1: dev->enetaddr[4 ] =get_random_hex (); dev->enetaddr[5 ] =get_random_hex ();#endif -eth_setenv_enetaddr (s, dev->enetaddr); +eth_setenv_enetaddr_by_index ("eth" , dev->index, + dev->enetaddr); } - dev->init = (void *)mvgbe_init; - dev->halt = (void *)mvgbe_halt; - dev->send = (void *)mvgbe_send; - dev->recv = (void *)mvgbe_recv; - dev->write_hwaddr = (void *)mvgbe_write_hwaddr; - -eth_register (dev); -#if defined(CONFIG_MII ) || defined(CONFIG_CMD_MII )miiphy_register (dev->name, smi_reg_read, smi_reg_write);/* Set phy address of the port */
include/net.h +12 -0
@@ -117,6 +117,18 @@ extern int eth_setenv_enetaddr(char *name, const uchar *enetaddr);extern int eth_getenv_enetaddr_by_index (const char *base_name,int index,uchar *enetaddr); +/* +* Set the hardware address for an ethernet interface. +* Args: +* base_name - base name for device (normally "eth") +* index - device index number (0 for first) +* enetaddr - returns 6 byte hardware address +* Returns: +* Return true if the environment varibable was set successfully. +*/ +extern int eth_setenv_enetaddr_by_index (const char *base_name,int index, +const uchar *enetaddr); +extern int usb_eth_initialize (bd_t *bi);extern int eth_init (bd_t *bis);/* Initialize the device */ extern int eth_send (volatile void *packet,int length);/* Send a packet */
net/eth.c +16 -1
@@ -54,14 +54,29 @@ int eth_setenv_enetaddr(char *name, const uchar *enetaddr)return setenv (name, buf); } +static void eth_get_enetaddr_env_name (char *buf,const char *base_name, +int index) +{ +sprintf (buf, index ?"%s%daddr" :"%saddr" , base_name, index); +return buf; +} +int eth_getenv_enetaddr_by_index (const char *base_name,int index,uchar *enetaddr) {char enetvar[32 ]; -sprintf (enetvar, index ?"%s%daddr" :"%saddr" , base_name, index); +eth_get_enetaddr_env_name (enetvar, base_name, index);return eth_getenv_enetaddr (enetvar, enetaddr); } +int eth_setenv_enetaddr_by_index (const char *base_name,int index, +const uchar *enetaddr) +{ +char enetvar[32 ]; +eth_get_enetaddr_env_name (enetvar, base_name, index); +return eth_setenv_enetaddr (enetvar, enetaddr); +} +static int eth_mac_skip (int index) {char enetvar[15 ];
Signature · 1 line
1.7.2.5
PATCH 2/2 mvgbe: fix network device indices
drivers/net/mvgbe.c error1: · line 730
Quoted 9 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
drivers/net/mvgbe.c +3
-0+/* 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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111103/2bd724db/attachment.pgp
PATCH 2/2 mvgbe: fix network device indices
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike Frysinger:
Quoted 8 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
Quoted 7 lines
drivers/net/mvgbe.c +3
-0+/* Extract the MAC address from the environment */ +while (!eth_getenv_enetaddr_by_index ("eth" , dev->index, + dev->enetaddr)) {
Quoted 6 lines
drivers/net/mvgbe.c error1: · line 730
Quoted 3 lines
drivers/net/mvgbe.c +0
-0/* 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.
Signature · 1 line
Michael
PATCH 2/2 mvgbe: fix network device indices
Quoted 16 lines · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike Frysinger:
Quoted 8 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
Quoted 7 lines
drivers/net/mvgbe.c +3
-0+/* Extract the MAC address from the environment */ +while (!eth_getenv_enetaddr_by_index ("eth" , dev->index, + dev->enetaddr)) {Quoted 6 lines
drivers/net/mvgbe.c error1: · line 730
Quoted 3 lines
drivers/net/mvgbe.c +0
-0/* 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.
Quoted 2 lines
i guess this whole mac randomization/generation code belongs to board specific files.
correct
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111103/dbdf1c96/attachment.pgp
PATCH 2/2 mvgbe: fix network device indices
Quoted 26 lines
-----Original Message-----
From: Mike Frysinger [mailto:vapier at gentoo.org]
Sent: Friday, November 04, 2011 4:42 AM
To: Michael Walle
Cc: u-boot at lists.denx.de; Prafulla Wadaskar; Wolfgang Denk
Subject: Re: [PATCH 2/2] mvgbe: fix network device indicesQuoted 1 line · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike
Frysinger:
Quoted 14 lines
Quoted 6 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
drivers/net/mvgbe.c error1:
Quoted 5 lines
drivers/net/mvgbe.c +2
-0+/* Extract the MAC address from the environment */ + while (!eth_getenv_enetaddr_by_index("eth", dev-index,
Quoted 7 lines
drivers/net/mvgbe.c error1: · line 730
Quoted 5 lines
drivers/net/mvgbe.c +1
-0+ 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
Quoted 8 lines
at all.
Quoted 3 lines
Quoted 1 line
please fix your driver to not do that first.
i guess this whole mac randomization/generation code belongs
to board
Quoted 1 line
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.
How about supporting standalone mac randomization feature?
Regards..
Prafulla . .
PATCH 2/2 mvgbe: fix network device indices
Quoted 18 lines · On Friday 04 November 2011 02:29:24 Prafulla Wadaskar wrote:
Mike Frysinger:
Quoted 17 lines · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Quoted 16 lines
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike Frysinger:
Quoted 14 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
drivers/net/mvgbe.c error1: · line 730
Quoted 10 lines
drivers/net/mvgbe.c +3
-0+/* 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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 1 line
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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111104/dfabf98a/attachment.pgp
PATCH 2/2 mvgbe: fix network device indices
Le 05/11/2011 00:06, Mike Frysinger a ?crit :
Quoted 34 lines · On Friday 04 November 2011 02:29:24 Prafulla Wadaskar wrote:
Quoted 18 lines
Mike Frysinger:
Quoted 17 lines · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Quoted 16 lines
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike Frysinger:
Quoted 14 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
drivers/net/mvgbe.c error1: · line 730
Quoted 10 lines
drivers/net/mvgbe.c +3
-0+/* 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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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->enetaddrfield in the first place. (2) drivers should be seedingdev->enetaddrwith 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.
Quoted 8 lines
that means this could should be moved to the boards file.
Quoted 1 line
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.
Quoted 1 line
-mike
Amicalement,
Signature · 1 line
Albert.
PATCH 2/2 mvgbe: fix network device indices
Dear Albert ARIBAUD,
Quoted 5 lines · In message <[email protected]> you wrote:
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.
What would be the result? A bord that comes up with a new MAC address each time you reset it?
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No journaling file system can recover your data if the disk dies.
- Steve Rago in <[email protected]>PATCH 2/2 mvgbe: fix network device indices
Hi Wolfgang,
Le 05/11/2011 14:21, Wolfgang Denk a ?crit :
Quoted 11 lines
Dear Albert ARIBAUD,
Quoted 5 lines · In message<[email protected]> you wrote:
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.
What would be the result? A bord that comes up with a new MAC address each time you reset it?
No -- the goal of the randomization code was, is, and will be to allow the board to use the network when no correct MAC address can be found anywhere (env vars, EEPROM, e-fuses, whatever). When a correct address is available, that address will be used. Typically, this happens when the board has not been provisioned yet, at a point where the MAC address it uses is not relevant yet.
Notes:
1. This code would only be available to kirkwood-based boards anyway.
2. Although the code incorrectly describes it as "private", the random address is actually a locally administered address (bit 1 of first octet is set), which eliminates the risk of clashing against any 'normal' (universally administered) address; and its last three octets are randomized in order to limit the risk of clashing against other locally administered addresses if we're unlucky enough to have any on the network segment.
Quoted 3 lines
Best regards,
Wolfgang Denk
Amicalement,
Signature · 1 line
Albert.
PATCH 2/2 mvgbe: fix network device indices
Dear Albert ARIBAUD,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines
What would be the result? A bord that comes up with a new MAC address each time you reset it?
No -- the goal of the randomization code was, is, and will be to allow the board to use the network when no correct MAC address can be found anywhere (env vars, EEPROM, e-fuses, whatever). When a correct address
And if this is the case, then the board will come up with a new MAC address each time you reset it, right?
Quoted 3 lines
is available, that address will be used. Typically, this happens when the board has not been provisioned yet, at a point where the MAC address it uses is not relevant yet.
I've done provisioning stuff a couple of times before, and I'm just doing is again. Random MAC addresses are a broken concept, and anybody who considers using it should reassess his concepts.
Where is the real MAC address coming from, and how does it get assigned to this specific board? And how do you make sure not to make mistakes when all you see is some board with a random MAC address?
[The systems I know usually either have the MAC address pre-programmed in some storage device on the board, or printed on a barcode label, so you can use ca barcode reader in combination with "askenv" and very little U-Boot scripting as part of your production test / initialization procedures.]
Quoted 1 line
1. This code would only be available to kirkwood-based boards anyway.
That doe snot make things any better.
Quoted 7 lines
2. Although the code incorrectly describes it as "private", the random address is actually a locally administered address (bit 1 of first octet is set), which eliminates the risk of clashing against any 'normal' (universally administered) address; and its last three octets are randomized in order to limit the risk of clashing against other locally administered addresses if we're unlucky enough to have any on the network segment.
I consider the whole approach broken and object against it.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-ExuperyPATCH 2/2 mvgbe: fix network device indices
In reply to Albert ARIBAUDQuoted 72 lines
-----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 indicesLe 05/11/2011 00:06, Mike Frysinger a ?crit :
Quoted 4 lines · On Friday 04 November 2011 02:29:24 Prafulla Wadaskar wrote:
Quoted 3 lines
Mike Frysinger:
Quoted 2 lines · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Quoted 1 line
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike
Frysinger:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · On Thursday 27 October 2011 17:31:36 Michael Walle wrote:
drivers/net/mvgbe.c
Quoted 4 lines
drivers/net/mvgbe.c +1
-0+/* Extract the MAC address from the environment */
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
drivers/net/mvgbe.c
Quoted 1 line
drivers/net/mvgbe.c +1
-0+ while (!eth_getenv_enetaddr_by_index("eth", dev-index,
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/net/mvgbe.c
Quoted 5 lines
drivers/net/mvgbe.c +1
-0+ 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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
at all. please fix your driver to not do that first.
i guess this whole mac randomization/generation code
belongs to board
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
specific files.
correct
We can move mac randomization code to the board specific
files, but it will
Quoted 3 lines
Quoted 1 line
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
Quoted 1 line
we have the
dev->enetaddrfield in the first place. (2)drivers should be
Quoted 1 line
seeding
dev->enetaddrwith values from storage directlyrelated to it. so for
Quoted 1 line
parts that have dedicated EEPROM interfaces, reading the MAC
out of that
Quoted 1 line
storage makes sense. if no storage like that exists, then it
is up to the
Quoted 7 lines
board to figure out where to find the address.
that means this could should be moved to the boards file.
Quoted 1 line
How about supporting standalone mac randomization feature?
i think Wolfgang would be opposed to that. mac randomization
should not be
Quoted 1 line
the first line of defense. your board is supposed to be
managing this sanely.
Quoted 1 line
from the mvgbe code, it seems that this is not the case and
these boards are a
Quoted 1 line
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).
Quoted 7 lines
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 . .
PATCH 2/2 mvgbe: fix network device indices
In reply to Mike FrysingerQuoted 59 lines
-----Original Message-----
From: Mike Frysinger [mailto:vapier at gentoo.org]
Sent: Saturday, November 05, 2011 4:37 AM
To: Prafulla Wadaskar
Cc: Michael Walle; u-boot at lists.denx.de; Wolfgang Denk
Subject: Re: [PATCH 2/2] mvgbe: fix network device indicesQuoted 3 lines · On Friday 04 November 2011 02:29:24 Prafulla Wadaskar wrote:
Mike Frysinger:
Quoted 2 lines · On Thursday 03 November 2011 19:02:26 Michael Walle wrote:
Quoted 1 line
Am Donnerstag 03 November 2011, 19:10:57 schrieb Mike
Frysinger:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Thursday 27 October 2011 17:31:36 Michael Walle
Quoted 4 lines · wrote:
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/net/mvgbe.c
Quoted 4 lines
drivers/net/mvgbe.c +1
-0+/* Extract the MAC address from the environment */
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
drivers/net/mvgbe.c
Quoted 1 line
drivers/net/mvgbe.c +1
-0+ while (!eth_getenv_enetaddr_by_index("eth", dev-index,
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/net/mvgbe.c error1: · line 730
Quoted 5 lines
drivers/net/mvgbe.c +1
-0+ 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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
at all. please fix your driver to not do that first.
i guess this whole mac randomization/generation code
belongs to board
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
specific files.
correct
We can move mac randomization code to the board specific
files, but it will
Quoted 1 line
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 thedev->enetaddrfield in the first place. (2) drivers should be
seedingdev->enetaddrwith 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.
Quoted 1 line
How about supporting standalone mac randomization feature?
Quoted 7 lines
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.
Hi Mike
I had posted feedback for your patch first and seen this email latter.
On some boards, using mvbge random mac generation is needed since there is no eeprom to hold this. Further practically it is not possible to hardcode mac address and recompile, nor it is suggested to have any mac/ip/server address definition in board config files.
Random mac address helps to resolve dhcp issues with more similar boards in the same network in such cases and will be applicable for any board.
Your patch is clean to abstract out mac randomization, on the other hand you should not remove the support for other boards which are already using it.
May be some more patches on the top to move support in board/arch specific files are needed. (if framework can not be entertained)
Regards..
Prafulla . .
PATCH 2/2 mvgbe: fix network device indices
Quoted 8 lines · On Tuesday 08 November 2011 02:32:59 Prafulla Wadaskar wrote:
On some boards, using mvbge random mac generation is needed since there is no eeprom to hold this. Further practically it is not possible to hardcode mac address and recompile, nor it is suggested to have any mac/ip/server address definition in board config files.
Random mac address helps to resolve dhcp issues with more similar boards in the same network in such cases and will be applicable for any board.
Quoted 6 lines
Your patch is clean to abstract out mac randomization, on the other hand you should not remove the support for other boards which are already using it.
May be some more patches on the top to move support in board/arch specific files are needed. (if framework can not be entertained)
i'm not the one to convince. i think Wolfgang addressed these already and still said no.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111108/93a1f23c/attachment.pgp