[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080106.002305.99653155.davem@davemloft.net>
Date: Sun, 06 Jan 2008 00:23:05 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: tsbogend@...ha.franken.de
Cc: netdev@...r.kernel.org, linux-mips@...ux-mips.org,
ralf@...ux-mips.org, jgarzik@...ox.com
Subject: Re: [PATCH] METH: fix MAC address handling
From: Thomas Bogendoerfer <tsbogend@...ha.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@...ha.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists