r8169: read MAC address from EEPROM on init
Subsystems (2)
PATCH 1/1 r8169: read MAC address from EEPROM on init
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.
--- drivers/net/r8169.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 79 insertions(+), 1 deletions(-)
drivers/net/r8169.c +79 -1
@@ -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);
Signature · 1 line
1.5.4.3
Quoted 25 lines · 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 <[email protected]>--- drivers/net/r8169.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 79 insertions(+), 1 deletions(-)drivers/net/r8169.c +5
-0@@ -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;
...
drivers/net/r8169.c static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp) · line 1937
Quoted 1 line
drivers/net/r8169.c +1
-0+ *val =cpu_to_le32 (value);
Did you check this with sparse?
Signature · 1 line
i.
Quoted 16 lines · 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 <[email protected]>--- drivers/net/r8169.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 79 insertions(+), 1 deletions(-)drivers/net/r8169.c +0
-0
...
drivers/net/r8169.c static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp) · line 1974
Quoted 11 lines
drivers/net/r8169.c +11
-0+* 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.
Signature · 1 line
i.
Quoted 6 lines · Ilpo Järvinen
Quoted 6 lines
(quoted diff) +6
-0+ * 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");
Quoted 8 lines
Review
Quoted 5 lines
(quoted diff) +5
-0+ 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(-)
drivers/net/r8169.c +73 -1
@@ -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);
Ilpo Järvinen
Reviewed-byQuoted 14 lines · Ivan Vecera
--- drivers/net/r8169.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 73 insertions(+), 1 deletions(-)drivers/net/r8169.c +5
-0+/* 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."
drivers/net/r8169.c static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp) · line 1976
Quoted 10 lines
drivers/net/r8169.c +10
-0+*/ +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.
Signature · 1 line
i.
Quoted 7 lines · Ilpo Järvinen
Aa, one more thing here, there's nowadays
print_mac()andDECLARE_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 <[email protected]>
OK :-), I hope the patch below is finally the right one.
Ivan
--- drivers/net/r8169.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 72 insertions(+), 1 deletions(-)
drivers/net/r8169.c +72 -1
@@ -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);
Signature · 1 line
1.5.4.3
Ivan Vecera <[email protected]> :
[...]
Quoted 1 line
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.
Signature · 1 line
Ueimor
Quoted 10 lines · Francois Romieu
Ivan Vecera <[email protected]> :
[...]Quoted 1 line
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
Quoted 7 lines · Ivan Vecera
Quoted 6 lines · Francois Romieu
Ivan Vecera <[email protected]> :
[...]Quoted 1 line
OK :-), I hope the patch below is finally the right one.
My approval ratings won't surge today.
Quoted 7 lines
Quoted 4 lines
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.
Signature · 3 lines
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.
Quoted 15 lines · Ben Hutchings
Quoted 6 lines · Ivan Vecera
Quoted 5 lines · Francois Romieu
Ivan Vecera <[email protected]> :
[...]Quoted 1 line
OK :-), I hope the patch below is finally the right one.
My approval ratings won't surge today.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 22 lines · On Thu, 25 Sep 2008 13:04:58 +0200 Ivan Vecera <[email protected]> wrote:
Quoted 21 lines · Ben Hutchings
Quoted 6 lines · Ivan Vecera
Quoted 5 lines · Francois Romieu
Ivan Vecera <[email protected]> :
[...]Quoted 1 line
OK :-), I hope the patch below is finally the right one.
My approval ratings won't surge today.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
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.