[PATCH] r8169: read MAC address from EEPROM on init

[PATCH] r8169: read MAC address from EEPROM on init

[Ivan Vecera]

This fixes the problem when MAC address is set by ifconfig or by
ip link commands and this address is stored in the device after
reboot. The power-off is needed to get right MAC address.
This is problem when Xen daemon is running because it renames the device
name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF.
After reboot the device is still using FE:FF:FF:FF:FF:FF.

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
 drivers/net/r8169.c |   80 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 79 insertions(+), 1 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index befc927..b09a4ec 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1910,6 +1910,81 @@ 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, u32 *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)
+{
+	u8 cfg1;
+	int vpd_cap;
+	u32 low, high;
+
+	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(tp->pci_dev, 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(tp->pci_dev, vpd_cap, 0x000e, &low) < 0 ||
+	    rtl_eeprom_read(tp->pci_dev, vpd_cap, 0x0012, &high) < 0) {
+		dprintk("Reading MAC address from EEPROM failed\n");
+		return;
+	}
+
+	/* Mask hi-word */
+	high &= 0xffff;
+
+	dprintk("MAC address found in EEPROM: "
+		"%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
+		((u8*)&low)[0], ((u8*)&low)[1], ((u8*)&low)[2],
+		((u8*)&low)[3], ((u8*)&high)[0], ((u8*)&high)[1]);
+
+	/* Write MAC address */
+	RTL_W8(Cfg9346, Cfg9346_Unlock);
+	RTL_W32(MAC0, low);
+	RTL_W32(MAC4, high);
+	RTL_W8(Cfg9346, Cfg9346_Lock);
+}
+
 static int __devinit
 rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
@@ -2079,7 +2154,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);
-- 
1.5.4.3

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ilpo Järvinen]

On Thu, 18 Sep 2008, Ivan Vecera wrote:

> This fixes the problem when MAC address is set by ifconfig or by
> ip link commands and this address is stored in the device after
> reboot. The power-off is needed to get right MAC address.
> This is problem when Xen daemon is running because it renames the device
> name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF.
> After reboot the device is still using FE:FF:FF:FF:FF:FF.
> 
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>  drivers/net/r8169.c |   80 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 79 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index befc927..b09a4ec 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1910,6 +1910,81 @@ 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, u32 *val)
> +{
> +	int ret, count = 100;
> +	u16 status = 0;
> +	u32 value;

...

> +	*val = cpu_to_le32(value);

Did you check this with sparse?


-- 
 i.

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ilpo Järvinen]

On Thu, 18 Sep 2008, Ivan Vecera wrote:
> This fixes the problem when MAC address is set by ifconfig or by
> ip link commands and this address is stored in the device after
> reboot. The power-off is needed to get right MAC address.
> This is problem when Xen daemon is running because it renames the device
> name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF.
> After reboot the device is still using FE:FF:FF:FF:FF:FF.
> 
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
>  drivers/net/r8169.c |   80 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 79 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index befc927..b09a4ec 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c

...

> +	 * is always consecutive 4-byte data starting from the VPD address
> +	 * specified."
> +	 */
> +	if (rtl_eeprom_read(tp->pci_dev, vpd_cap, 0x000e, &low) < 0 ||
> +	    rtl_eeprom_read(tp->pci_dev, vpd_cap, 0x0012, &high) < 0) {
> +		dprintk("Reading MAC address from EEPROM failed\n");
> +		return;
> +	}
> +
> +	/* Mask hi-word */
> +	high &= 0xffff;

...Hmm, and besides fixing sparse printouts, this looks like a real 
endianness bug.


-- 
 i.

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ivan Vecera]

Ilpo Järvinen wrote:
>> +	 * is always consecutive 4-byte data starting from the VPD address
>> +	 * specified."
>> +	 */
>> +	if (rtl_eeprom_read(tp->pci_dev, vpd_cap, 0x000e, &low) < 0 ||
>> +	    rtl_eeprom_read(tp->pci_dev, vpd_cap, 0x0012, &high) < 0) {
>> +		dprintk("Reading MAC address from EEPROM failed\n");
>> +		return;
>> +	}
>> +
>> +	/* Mask hi-word */
>> +	high &= 0xffff;
> 
> ..Hmm, and besides fixing sparse printouts, this looks like a real 
> endianness bug.

Yes it is, my mistake. The patch below will be better.

---
 drivers/net/r8169.c |   74 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 73 insertions(+), 1 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index befc927..cff8dd6 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1910,6 +1910,75 @@ 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];
+
+	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: "
+		"%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
+		mac[0], mac[1], mac[2], mac[3], mac[4], mac[5], mac[6]);
+
+	/* 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 +2148,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);

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ilpo Järvinen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1295 bytes --]

On Fri, 19 Sep 2008, Ivan Vecera wrote:

> ---
>  drivers/net/r8169.c |   74 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 73 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index befc927..cff8dd6 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c

> +	/* 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: "
> +		"%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
> +		mac[0], mac[1], mac[2], mac[3], mac[4], mac[5], mac[6]);

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>


-- 
 i.

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ivan Vecera]

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(-)

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);
-- 
1.5.4.3

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Francois Romieu]

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.

-- 
Ueimor

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ivan Vecera]

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

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ben Hutchings]

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.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Ivan Vecera]

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.

Re: [PATCH] r8169: read MAC address from EEPROM on init

[Stephen Hemminger]

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.