[PATCH] METH: fix MAC address handling

[PATCH] METH: fix MAC address handling

[Thomas Bogendoerfer]

meth didn't set a valid mac address during probing, but later during
open. Newer kernel refuse to open device with 00:00:00:00:00:00 as
mac address -> dead ethernet. This patch sets the mac address in
the probe function and uses only the mac address from the netdevice
struct when setting up the hardware.

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---

 drivers/net/meth.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index 0c89b02..cdaa8fc 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -95,11 +95,14 @@ static inline void load_eaddr(struct net_device *dev)
 {
 	int i;
 	DECLARE_MAC_BUF(mac);
+	u64 macaddr;
 
-	for (i = 0; i < 6; i++)
-		dev->dev_addr[i] = o2meth_eaddr[i];
 	DPRINTK("Loading MAC Address: %s\n", print_mac(mac, dev->dev_addr));
-	mace->eth.mac_addr = (*(unsigned long*)o2meth_eaddr) >> 16;
+	macaddr = 0;
+	for (i = 0; i < 6; i++)
+		macaddr |= dev->dev_addr[i] << ((5 - i) * 8);
+
+	mace->eth.mac_addr = macaddr;
 }
 
 /*
@@ -794,6 +797,7 @@ static int __init meth_probe(struct platform_device *pdev)
 #endif
 	dev->irq	     = MACE_ETHERNET_IRQ;
 	dev->base_addr	     = (unsigned long)&mace->eth;
+	memcpy(dev->dev_addr, o2meth_eaddr, 6);
 
 	priv = netdev_priv(dev);
 	spin_lock_init(&priv->meth_lock);

Re: [PATCH] METH: fix MAC address handling

[David Miller]

From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Sat,  5 Jan 2008 23:48:42 +0100 (CET)

> meth didn't set a valid mac address during probing, but later during
> open. Newer kernel refuse to open device with 00:00:00:00:00:00 as
> mac address -> dead ethernet. This patch sets the mac address in
> the probe function and uses only the mac address from the netdevice
> struct when setting up the hardware.
> 
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>

Applied, thanks.

> +	u64 macaddr;
>  
> -	for (i = 0; i < 6; i++)
> -		dev->dev_addr[i] = o2meth_eaddr[i];
>  	DPRINTK("Loading MAC Address: %s\n", print_mac(mac, dev->dev_addr));
> -	mace->eth.mac_addr = (*(unsigned long*)o2meth_eaddr) >> 16;
> +	macaddr = 0;
> +	for (i = 0; i < 6; i++)
> +		macaddr |= dev->dev_addr[i] << ((5 - i) * 8);
> +
> +	mace->eth.mac_addr = macaddr;
>  }
>  
>  /*

Can you double-check that this conversion is equivalent.

I know that this whole driver is full of assumptions about
the endianness of the system this chip is found on, so
I'm only interested in if the transformation is equivalent
and the driver will keep working properly.

Thanks.

Re: [PATCH] METH: fix MAC address handling

[Thomas Bogendoerfer]

On Sun, Jan 06, 2008 at 12:23:05AM -0800, David Miller wrote:
> > +	u64 macaddr;
> >  
> > -	for (i = 0; i < 6; i++)
> > -		dev->dev_addr[i] = o2meth_eaddr[i];
> >  	DPRINTK("Loading MAC Address: %s\n", print_mac(mac, dev->dev_addr));
> > -	mace->eth.mac_addr = (*(unsigned long*)o2meth_eaddr) >> 16;
> > +	macaddr = 0;
> > +	for (i = 0; i < 6; i++)
> > +		macaddr |= dev->dev_addr[i] << ((5 - i) * 8);
> > +
> > +	mace->eth.mac_addr = macaddr;
> >  }
> >  
> >  /*
> 
> Can you double-check that this conversion is equivalent.

yes, I did.

> I know that this whole driver is full of assumptions about
> the endianness of the system this chip is found on, so
> I'm only interested in if the transformation is equivalent
> and the driver will keep working properly.

I've tested the driver and it's still working :-)

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] METH: fix MAC address handling

[David Miller]

From: tsbogend@alpha.franken.de (Thomas Bogendoerfer)
Date: Sun, 6 Jan 2008 12:38:16 +0100

> On Sun, Jan 06, 2008 at 12:23:05AM -0800, David Miller wrote:
> > I know that this whole driver is full of assumptions about
> > the endianness of the system this chip is found on, so
> > I'm only interested in if the transformation is equivalent
> > and the driver will keep working properly.
> 
> I've tested the driver and it's still working :-)

Great :)