Alan Cox wrote:
quoted text
> On Tue, 16 Oct 2007 18:10:53 +0400
> Konstantin Kalin <konstantin.kalin@gmail.com> wrote:
>
>   
>> Hello,
>>
>> Recently we've got some computers with new motherboard having NVidia 
>> chipset. The motherboard has nforce12 & nforce13 Ethernet cards. I've 
>> noticed that MAC address is setup random each boot. I debugged the 
>> driver and found that these cards have right-byte order of MAC address 
>> but the driver is expecting incorrect byte-order for these models.
>>     
>
> The only obvious thing I can think of to try would be to read the MAC
> address both ways around.
>
> The first 3 bytes of the resulting MAC should always be the Nvidia
> allocation as I understand it and if so you can then decide which way
> around is correct. 
>
> ie if it starts 00:04:0B then you know which way around it goes. (there
> is one address that is the same either way around but clearly that one
> doesn't matter).
>
> So perhaps do that and for the afflicted parts add an EITHER_WAY_AROUND
> flag ?
>
> Alan
>
>   

Hello,

I thought a bit today and made a patch. The patch adds new parameter to 
the driver that allows initializing MAC by manually. There is an issue 
that I didn't fix - if the driver has been loaded with wrong MAC 
detection when the parameter works inversely due to the driver replaces 
original mac. Please look at these line in "nv_probe" function:
 /* set permanent address to be correct aswell */
     np->orig_mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) +
....

P.S. The patch is based on vanila 2.6.21-7 because we use it in our 
servers.

Thank you,
Kostya.

-------------------------------------------------------------------------------------------------

--- linux-2.6.21.x86_64/drivers/net/forcedeth.c.orig    2007-10-17 
11:07:09.000000000 +0400
+++ linux-2.6.21.x86_64/drivers/net/forcedeth.c 2007-10-17 
11:07:32.000000000 +0400
@@ -850,6 +850,15 @@
 };
 static int dma_64bit = NV_DMA_64BIT_ENABLED;

+enum {
+       NV_FORCING_MAC_DISABLED = 0,
+       NV_FORCE_MAC_CORRECT_ORDER,
+       NV_FORCE_MAC_INVERSE_ORDER
+};
+
+static int force_mac = NV_FORCING_MAC_DISABLED;
+
+
 static inline struct fe_priv *get_nvpriv(struct net_device *dev)
 {
        return netdev_priv(dev);
@@ -4844,6 +4853,7 @@
        u32 powerstate, txreg;
        u32 phystate_orig = 0, phystate;
        int phyinitialized = 0;
+       bool mac_address_correct = false;

        dev = alloc_etherdev(sizeof(struct fe_priv));
        err = -ENOMEM;
@@ -5032,7 +5043,16 @@

        /* check the workaround bit for correct mac address order */
        txreg = readl(base + NvRegTransmitPoll);
-       if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+
+       /* Since Vendors begin fixing MAC address in oldest version of 
Etherenet card we should provide a way to initialize MAC by parameter */
+       mac_address_correct = (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) 
|| (force_mac == NV_FORCE_MAC_CORRECT_ORDER);
+       printk(KERN_DEBUG "force_mac=%d, txreg=%d, 
mac_address_correct=%d\n", force_mac, txreg, mac_address_correct);
+       if (force_mac == NV_FORCE_MAC_INVERSE_ORDER)
+       {
+               mac_address_correct = false;
+       }
+
+       if (mac_address_correct) {
                /* mac address is already in correct order */
                dev->dev_addr[0] = (np->orig_mac[0] >>  0) & 0xff;
                dev->dev_addr[1] = (np->orig_mac[0] >>  8) & 0xff;
@@ -5444,6 +5461,8 @@
 MODULE_PARM_DESC(msix, "MSIX interrupts are enabled by setting to 1 and 
disabled by setting to 0.");
 module_param(dma_64bit, int, 0);
 MODULE_PARM_DESC(dma_64bit, "High DMA is enabled by setting to 1 and 
disabled by setting to 0.");
+module_param(force_mac, int, 0);
+MODULE_PARM_DESC(force_mac, "Force MAC address in correct/inverse byte 
order. 0 - do nothing, 1 - correct order, 2 -inverse order");

 MODULE_AUTHOR("Manfred Spraul <manfred@colorfullife.com>");
 MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver");

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/