Message-ID: <trinity-9c3b63ff-f474-4d99-84d8-29034921bb3c-1416183467662@3capp-webde-bs06>
Date:	Mon, 17 Nov 2014 01:17:47 +0100
From:	"Roland Kletzing" <devzero@....de>
To:	netdev@...r.kernel.org
Subject: [PATCH] fix #51791 - bug? mac 00:00:00:00:00:00 with natsemi
 DP83815 after driver load

This one should fix Bugzilla #51791 (details below). 

Natsemi driver does not read MAC correctly from eeprom, while natsemi-diag from nictools-pci does. Apparently, tt`s a timing issue in the kernel driver.

According to ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c , eeprom_delay(ee_addr) is defined as follows:

/* Delay between EEPROM clock transitions.
   This flushes the write buffer to prevent quick double-writes.
*/
#define eeprom_delay(ee_addr) 	inl(ee_addr); inl(ee_addr)

while in the natsemi linux kernel driver, the delay is done this way :

#define eeprom_delay(ee_addr)   readl(ee_addr)

, which results in the MAC being all zero`s.

So i simply added a second readl() to increase delay (instead of turning into inl() as proposed before). This may look a little bit ugly, but it`s fixing the problem for me.

I´m not sure how many natsemi users being left on this planet (probably few), but i guess this change does not do any harm on platforms where the driver does not behave buggy, so please consider adding it to mainline/stable/longterm.

Signed-off-by: Roland Kletzing <devzero@....de>

---
 drivers/net/ethernet/natsemi/natsemi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/natsemi/natsemi.c b/drivers/net/ethernet/natsemi/natsemi.c
index b83f7c0..246bb91 100644
--- a/drivers/net/ethernet/natsemi/natsemi.c
+++ b/drivers/net/ethernet/natsemi/natsemi.c
@@ -987,7 +987,7 @@ static int natsemi_probe1(struct pci_dev *pdev, const struct pci_device_id *ent)
    The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
    deprecated.
 */
-#define eeprom_delay(ee_addr)  readl(ee_addr)
+#define eeprom_delay(ee_addr)  readl(ee_addr); readl(ee_addr)

 #define EE_Write0 (EE_ChipSelect)
 #define EE_Write1 (EE_ChipSelect | EE_DataIn)
--


regards
Roland


> Gesendet: Sonntag, 16. November 2014 um 01:05 Uhr
> Von: devzero@....de
> An: linux-kernel@...r.kernel.org
> Betreff: re: bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
>
> forwarding to lkml, as no response on netdev list so far.
>  
> maybe someone has a clue how to properly fix this timing issue.  the remaining question is about how to correctly replace readl() with inl() to make it compile cleanly or how eeprom_delay() is being done correctly.  inl() seems to be slower to complete which seems to make the driver work, but it seems it needs an I/O port as param but not an memory-adress. 
> 
> sorry, i`m not good at programming, but now as the problem is "basically" fixed there are just some tiny bits missing for a proper fix. i´m unsure if typecasting ee_addr is the right thing to do (i think it`s not) and if a patch with such typecast would have any chance for being accepted.
> 
> ----------------------------
> hi,
> as i`m doing a little project with this older devices, i have come across this issue again and had some fun to dig deeper into it.
> 
> it`s a little bit academic, as i can do ifconfig eth0 hw ether..... as a workaround, but it sucks to hack that into startup scripts and i also have seen udev not playing nicely with it.
> 
> apparently the problem is being caused by a timing issue in the natsemi driver.
> 
> i added some debug printk`s in natsemi.c -> eeprom_read() after each occurrence of eeprom_delay(ee_addr); , and the problem went away. 
> 
> there is a hint about timing sensitivity in the code:
> 
> /* Delay between EEPROM clock transitions.
>    No extra delay is needed with 33Mhz PCI, but future 66Mhz access may need
>    a delay.  Note that pre-2.0.34 kernels had a cache-alignment bug that
>    made udelay() unreliable.
>    The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is
>    deprecated.
> */
> 
> looking at the source of natsemi-diag.c made me wonder why that utility is using 
> 
> #define eeprom_delay(ee_addr)   inl(ee_addr)
> 
> instead of 
> 
> #define eeprom_delay(ee_addr)   readl(ee_addr)
> 
> and apparently, that also fixes the problem (but gives a compile warning):
> 
> drivers/net/ethernet/natsemi/natsemi.c: In function âeeprom_readâ:
> drivers/net/ethernet/natsemi/natsemi.c:1019:3: warning: passing argument 1 of âinlâ makes integer from pointer without a cast [enabled by default]
> In file included from include/linux/io.h:22:0,
>                  from include/linux/pci.h:54,
>                  from drivers/net/ethernet/natsemi/natsemi.c:38:
> 
> 
> looking at a more recent version of natsemi-diag.c ,  i even found this one:
> 
> ftp://ftp.gwdg.de/pub/linux/misc/donald.becker/diag/natsemi-diag.c
> 
> /* Delay between EEPROM clock transitions.
>    This flushes the write buffer to prevent quick double-writes.
> */
> #define eeprom_delay(ee_addr)	inl(ee_addr); inl(ee_addr)
> 
> The question is how to make a proper fix, as i don`t know what to pass to inl() , as it seems it should not get an mmapped adress but an i/o port instead !?
> 
> "The  in*() functions return data read from the specified I/O port"
> 
> "The read*() functions read data from device memory previously mapped by map_memory()"
> 
> regards
> roland
> 
> ps: CC driver maintainer from Kernel Maintainers file.
> 
> 
> 
> Roland Kletzing | 17 Dec 13:38 2012
> bug? mac 00:00:00:00:00:00 with natsemi DP83815 after driver load
> 
> Hello,
> i recently played with my older evo t20/wyse 3235le thin clients and flashed
> a linux kernel into those, apparently there seems an issue with the natsemi
> driver.
> 
> after driver load (natsemi.ko) eth0 has no valid mac adress, dmesg and
> ifconfig shows just zero`s: 00:00:00:00:00:00.
> 
> despite that , the nic is working fine for me (in this test setup i set the
> mac manually: ifconfig eth0 hw ether de:ad:be:ef:be:ef )
> 
> apparently, the driver fails to read the proper mac from the eeprom, as
> "natsemi-diag -ee" (from nictools-pci in debian squeeze) shows, that there
> is a valid "Ethernet MAC Station Address" stored inside the eeprom. (see
> below)
> 
> looks like a driver bug !?
> does anybody have a clue what`s going wrong here?
> 
> regards
> roland
> 
> #lspci
> 
> 00:00.0 Host bridge: Cyrix Corporation PCI Master
> 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815
> (MacPhyter) Ethernet Controller
> 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
> 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
> 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua]
> 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
> 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
> 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev
> 06)
> 
> #dmesg |egrep "natsemi|eth"
> natsemi dp8381x driver, version 2.1, Sept 11, 2006
> natsemi 0000:00:0f.0: setting latency timer to 64
> natsemi eth0: NatSemi DP8381[56] at 0x4010000 (0000:00:0f.0),
> 00:00:00:00:00:00, IRQ 10, port TP.
> eth0: DSPCFG accepted after 0 usec.
> eth0: link up.
> eth0: Setting full-duplex based on negotiated link capability.
> 
> #natsemi-diag -aa
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
>  Natsemi 83815 series with station address de:ad:be:ef:be:ef
>  Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
>  This device appears to be active, so some registers will not be read.
>  To see all register values use the '-f' flag.
> NatSemi DP83815 chip registers at 0xf800
>  0x000: 00000004 e805e000 00000002 00000000 ******** 00f1cd65 00000001
> 00000000
>  0x020: 03abd200 d0f01002 00000000 00000000 03abd000 18700010 00000000
> 00000000
>  0x040: ******** 00200000 00000004 0000efbe ffff000b 30303030 00000403
> 00000000
>  0x060: ******** ******** ******** ******** ******** ******** ********
> ********
>  0x080: 00003100 0000786d 00002000 00005c21 000005e1 000045e1 00000005
> 00002801
>  0x0A0: ******** ******** ******** ******** ******** ******** ********
> ********
>  0x0C0: 00000615 00000002 00000000 00000000 00000000 00000000 00000100
> 00000030
>  0x0E0: 00000000 000000bf 00000804 00008200 00000000 00000000 00000000
> 00000000
>   Interrupt sources are pending (00000200).
>    Tx queue emptied indication.
>   Receive mode is 0xc8200000: Normal unicast and hashed multicast.
>   Rx filter contents:   adde efbe efbe 0000 0000 0000 0000 0000
> 
> #natsemi-diag -ee
> natsemi-diag.c:v2.08 2/28/2005 Donald Becker (becker <at> scyld.com)
>  http://www.scyld.com/diag/index.html
> Index #1: Found a NatSemi DP83815 adapter at 0xf800.
>  Natsemi 83815 series with station address de:ad:be:ef:be:ef
>  Transceiver setting Autonegotation advertise 10/100 Mbps half and full
> duplex.
>  EEPROM address length 6, 64 words.
> EEPROM contents (64 words):
> 0x00:  100b 0020 0b34 41fb 0000 0000 0000 4000
> 0x08:  0d32 dff4 1905 aa48 0000 0000 129c 4c4c
> 0x10:  ca52 2ccc 0cb2 9c6c 0c6c 8c0c 2020 6080
> 0x18:  0800 0000 0000 0000 0000 0000 0000 0000
> 0x20:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x28:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x30:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x38:  0000 0000 0000 0000 0000 0000 0000 e418
> Decoded EEPROM contents:
>   PCI Subsystem IDs -- Vendor 0x100b, Device 0x0020.
>   PCI timer settings -- minimum grant 11, maximum latency 52.
>   Ethernet MAC Station Address 00:80:64:1a:e8:bf.
>   Wake-On-LAN password 00:00:00:00:00:00.
>   Transceiver setting 0x--f-: advertise 10/100 Mbps half and full duplex.
>    Flow control enabled.
>   EEPROM active region checksum read as aa48, vs aa48 calculated value.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists