Patchwork r8169: read MAC address from EEPROM on init

login
register
mail settings
Submitter Ivan Vecera
Date Sept. 24, 2008, 8:46 a.m.
Message ID <48D9FE65.40709@redhat.com>
Download mbox | patch
Permalink /patch/1251/
State Accepted
Delegated to: Jeff Garzik
Headers show

Comments

Ivan Vecera - Sept. 24, 2008, 8:46 a.m.
Ilpo Järvinen wrote:
> Aa, one more thing here, there's nowadays print_mac() and 
> DECLARE_MAC_BUF() for printing MAC-addresses using %s. Since this is 
> not perf-critical in anyway here, it will save some bytes when used in 
> kernel-wide scale.
> 
> 
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
OK :-), I hope the patch below is finally the right one.

Ivan

---
 drivers/net/r8169.c |   73 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 72 insertions(+), 1 deletions(-)
françois romieu - Sept. 24, 2008, 9:10 p.m.
Ivan Vecera <ivecera@redhat.com> :
[...]
> OK :-), I hope the patch below is finally the right one.

My approval ratings won't surge today.

Is there a specific explanation for the 10 us delay ?

Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
10 ms delay. I would not mind a 10 ms sleep.
Ivan Vecera - Sept. 25, 2008, 9:38 a.m.
Francois Romieu wrote:
> Ivan Vecera <ivecera@redhat.com> :
> [...]
>> OK :-), I hope the patch below is finally the right one.
> 
> My approval ratings won't surge today.
> 
> Is there a specific explanation for the 10 us delay ?
> 
> Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
> 10 ms delay. I would not mind a 10 ms sleep.
'pci_vpd_pci22_wait' uses 100us(10x10us delay) for reading, there is 1ms
(100x10us delay) in my patch, because 100us max. delay was too little for
Realtek. I tried the patch (with 1ms) on 8169,8168b and 8102e HW without
any problem. IMHO Realtek's 10ms delay (usually used for VPD write access)
is too much...

Ivan

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Hutchings - Sept. 25, 2008, 10:24 a.m.
On Thu, 2008-09-25 at 11:38 +0200, Ivan Vecera wrote:
> Francois Romieu wrote:
> > Ivan Vecera <ivecera@redhat.com> :
> > [...]
> >> OK :-), I hope the patch below is finally the right one.
> > 
> > My approval ratings won't surge today.
> > 
> > Is there a specific explanation for the 10 us delay ?
> > 
> > Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
> > 10 ms delay. I would not mind a 10 ms sleep.
> 'pci_vpd_pci22_wait' uses 100us(10x10us delay) for reading, there is 1ms
> (100x10us delay) in my patch, because 100us max. delay was too little for
> Realtek.

If the maximum delay there is too short, it should be increased.  As
I've said before, I picked a timeout that worked for me in the absence
of any time limit in the PCI specification.  I thought Stephen Hemminger
had modified it to work for sky2 but it looks like that change was
blocked by quibbling about how best to poll.

Ben.
Ivan Vecera - Sept. 25, 2008, 11:04 a.m.
Ben Hutchings wrote:
> On Thu, 2008-09-25 at 11:38 +0200, Ivan Vecera wrote:
>> Francois Romieu wrote:
>>> Ivan Vecera <ivecera@redhat.com> :
>>> [...]
>>>> OK :-), I hope the patch below is finally the right one.
>>> My approval ratings won't surge today.
>>>
>>> Is there a specific explanation for the 10 us delay ?
>>>
>>> Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
>>> 10 ms delay. I would not mind a 10 ms sleep.
>> 'pci_vpd_pci22_wait' uses 100us(10x10us delay) for reading, there is 1ms
>> (100x10us delay) in my patch, because 100us max. delay was too little for
>> Realtek.
> 
> If the maximum delay there is too short, it should be increased.  As
> I've said before, I picked a timeout that worked for me in the absence
> of any time limit in the PCI specification.  I thought Stephen Hemminger
> had modified it to work for sky2 but it looks like that change was
> blocked by quibbling about how best to poll.
> 
> Ben.
Yes, I did the same for r8169. 100us total was too short so I increase
total possible delay to 1 ms. Some net drivers use infinite loop with
flag testing but I think it isn't good approach and 10ms hard delay is
a little bit long.

Ivan.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
stephen hemminger - Sept. 25, 2008, 4:44 p.m.
On Thu, 25 Sep 2008 13:04:58 +0200
Ivan Vecera <ivecera@redhat.com> wrote:

> Ben Hutchings wrote:
> > On Thu, 2008-09-25 at 11:38 +0200, Ivan Vecera wrote:
> >> Francois Romieu wrote:
> >>> Ivan Vecera <ivecera@redhat.com> :
> >>> [...]
> >>>> OK :-), I hope the patch below is finally the right one.
> >>> My approval ratings won't surge today.
> >>>
> >>> Is there a specific explanation for the 10 us delay ?
> >>>
> >>> Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
> >>> 10 ms delay. I would not mind a 10 ms sleep.
> >> 'pci_vpd_pci22_wait' uses 100us(10x10us delay) for reading, there is 1ms
> >> (100x10us delay) in my patch, because 100us max. delay was too little for
> >> Realtek.
> > 
> > If the maximum delay there is too short, it should be increased.  As
> > I've said before, I picked a timeout that worked for me in the absence
> > of any time limit in the PCI specification.  I thought Stephen Hemminger
> > had modified it to work for sky2 but it looks like that change was
> > blocked by quibbling about how best to poll.
> > 
> > Ben.
> Yes, I did the same for r8169. 100us total was too short so I increase
> total possible delay to 1 ms. Some net drivers use infinite loop with
> flag testing but I think it isn't good approach and 10ms hard delay is
> a little bit long.
> 
> Ivan.
> 

Worst case on Marvell chips is 20ms. So the revised code did retry after
1ms. The important thing is with my code it doesn't run under lock with irq disabled,
but uses mutex instead.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index befc927..e979cf5 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1910,6 +1910,74 @@  static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp)
 	}
 }

+static int rtl_eeprom_read(struct pci_dev *pdev, int cap, int addr, __le32 *val)
+{
+	int ret, count = 100;
+	u16 status = 0;
+	u32 value;
+
+	ret = pci_write_config_word(pdev, cap + PCI_VPD_ADDR, addr);
+	if (ret < 0)
+		return ret;
+
+	do {
+		udelay(10);
+		ret = pci_read_config_word(pdev, cap + PCI_VPD_ADDR, &status);
+		if (ret < 0)
+			return ret;
+	} while (!(status & PCI_VPD_ADDR_F) && --count);
+
+	if (!(status & PCI_VPD_ADDR_F))
+		return -ETIMEDOUT;
+
+	ret = pci_read_config_dword(pdev, cap + PCI_VPD_DATA, &value);
+	if (ret < 0)
+		return ret;
+
+	*val = cpu_to_le32(value);
+
+	return 0;
+}
+
+static void rtl_init_mac_address(struct rtl8169_private *tp,
+				 void __iomem *ioaddr)
+{
+	struct pci_dev *pdev = tp->pci_dev;
+	u8 cfg1;
+	int vpd_cap;
+	u8 mac[8];
+	DECLARE_MAC_BUF(buf);
+
+	cfg1 = RTL_R8(Config1);
+	if (!(cfg1  & VPD)) {
+		dprintk("VPD access not enabled, enabling\n");
+		RTL_W8(Cfg9346, Cfg9346_Unlock);
+		RTL_W8(Config1, cfg1 | VPD);
+		RTL_W8(Cfg9346, Cfg9346_Lock);
+	}
+
+	vpd_cap = pci_find_capability(pdev, PCI_CAP_ID_VPD);
+	if (!vpd_cap)
+		return;
+
+	/* MAC address is stored in EEPROM at offset 0x0e
+	 * Realtek says: "The VPD address does not have to be a DWORD-aligned
+	 * address as defined in the PCI 2.2 Specifications, but the VPD data
+	 * is always consecutive 4-byte data starting from the VPD address
+	 * specified."
+	 */
+	if (rtl_eeprom_read(pdev, vpd_cap, 0x000e, (__le32*)&mac[0]) < 0 ||
+	    rtl_eeprom_read(pdev, vpd_cap, 0x0012, (__le32*)&mac[4]) < 0) {
+		dprintk("Reading MAC address from EEPROM failed\n");
+		return;
+	}
+
+	dprintk("MAC address found in EEPROM: %s\n", print_mac(buf, mac));
+
+	/* Write MAC address */
+	rtl_rar_set(tp, mac);
+}
+
 static int __devinit
 rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
@@ -2079,7 +2147,10 @@  rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 		dev->do_ioctl = rtl8169_ioctl;
 	}

-	/* Get MAC address.  FIXME: read EEPROM */
+	/* Read MAC address from EEPROM */
+	rtl_init_mac_address(tp, ioaddr);
+
+	/* Get MAC address */
 	for (i = 0; i < MAC_ADDR_LEN; i++)
 		dev->dev_addr[i] = RTL_R8(MAC0 + i);
 	memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);