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