public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Kalin <konstantin.kalin@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: NVIDIA Ethernet & invalid MAC
Date: Wed, 17 Oct 2007 17:08:49 +0400	[thread overview]
Message-ID: <47160961.7040607@gmail.com> (raw)
In-Reply-To: <20071016154313.53d19c43@the-village.bc.nu>

Alan Cox wrote:
> 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");


  parent reply	other threads:[~2007-10-17 13:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16 14:10 NVIDIA Ethernet & invalid MAC Konstantin Kalin
2007-10-16 14:43 ` Alan Cox
2007-10-16 15:16   ` Chuck Ebbert
2007-10-16 15:43     ` Alan Cox
2007-10-16 16:00       ` Jeff Garzik
2007-10-16 16:20         ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-16 16:35         ` Konstantin Kalin
2007-10-16 16:41           ` Jeff Garzik
2007-10-16 16:52             ` Konstantin Kalin
2007-10-17 13:08   ` Konstantin Kalin [this message]
2007-10-16 16:00 ` Chris Snook
2007-10-16 16:07   ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47160961.7040607@gmail.com \
    --to=konstantin.kalin@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox