From nobody@FreeBSD.org  Sat Mar  2 08:39:46 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 9224937B400
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  2 Mar 2002 08:39:45 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g22Gdjr25609;
	Sat, 2 Mar 2002 08:39:45 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200203021639.g22Gdjr25609@freefall.freebsd.org>
Date: Sat, 2 Mar 2002 08:39:45 -0800 (PST)
From: Ted Stockwell <tstockwell@visi.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: dc driver uses wrong case to read MAC from eeprom.  fix included
X-Send-Pr-Version: www-1.0

>Number:         35482
>Category:       kern
>Synopsis:       dc driver uses wrong case to read MAC from eeprom.  fix included
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mbr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 02 08:40:01 PST 2002
>Closed-Date:    Wed Feb 19 16:35:58 PST 2003
>Last-Modified:  Wed Feb 19 16:35:58 PST 2003
>Originator:     Ted Stockwell
>Release:        RELENG_4 tag, late feb 2002
>Organization:
self
>Environment:
FreeBSD test.mesabi-tech.com 4.5-STABLE FreeBSD 4.5-STABLE #11: Thu Feb 28 16:03:27 CST 2002     ted@dev.mesabi-tech.com:/usr/users/ted/mip/sys/compile/MIP_144  i386
>Description:
The Siemens SpeedStream SS1020 is recognized by the dc driver as an
Accton EN2242.  The vendor and device ids match that of the EN2242,
but the part is actually an EN5251B and it does not work quite
correctly.  Most notably, the MAC address is wrong.

The Accton EN2242 is handled by the driver as being of type
DC_TYPE_AN985.  This seems to be mostly correct, however, the code
assumes that AN985 implies that the EEPROM is a 93c66.  The part on
the SS1020 board is a 93LC46.  My diffs create a new type that follows
the AN985, except for the EEPROM type.

I do not have access to the Accton EN2242, and so I cannot confirm
that my fix did not break support for that board.  Because their device
and vendor IDs match, I had to _assume_ that the revision numbers
differed. 

The Siemens board uses a chip labeled Accton EN5251B.  The Siemens
board appears to be identical to this Accton board:

  http://www.acctontech.com/pdf/EN1207FTX_WOL.pdf

The Siemes board is here:
  http://www.efficient.com/pdf/products/1012_1020.pdf


One resource I found on the net suggested that the EN5251 was really a
clone of the ADMtek 983.  I do not know how the 983 differs from the
the 985 or 981 which are explicitly supported in by the dc driver.

One point about this code that merits review is the use of the
DC_IS_CENTAUR() macro.  Should the DC_IS_CENTAUR be used in
dc_eeprom_putbyte(), in which case the EN5251B is not a CENTAUR.  Or,
should the test in dc_eeprom_putbyte() test explicitly for the 985, in
which case the new DC_TYPE_EN5152B type should be added to
DC_IS_CENTAUR.

>How-To-Repeat:
run ifconfig with a Siemens SpeedStream SS1020, 
and look at the value of the MAC address
>Fix:
Index: if_dcreg.h
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v
retrieving revision 1.4.2.16
diff -u -r1.4.2.16 if_dcreg.h
--- if_dcreg.h	2002/02/26 04:21:30	1.4.2.16
+++ if_dcreg.h	2002/03/01 04:21:40
@@ -76,6 +76,7 @@
 #define DC_TYPE_PNICII		0x9	/* 82c115 PNIC II */
 #define DC_TYPE_PNIC		0xA	/* 82c168/82c169 PNIC I */
 #define DC_TYPE_CONEXANT        0xC     /* Conexant LANfinity RS7112 */
+#define DC_TYPE_EN5152B		0xD	/* Accton EN5251B. Clone of ADMtek 983B? */
 
 #define DC_IS_MACRONIX(x)			\
 	(x->dc_type == DC_TYPE_98713 ||		\
@@ -84,6 +85,7 @@
 
 #define DC_IS_ADMTEK(x)				\
 	(x->dc_type == DC_TYPE_AL981 ||		\
+	 x->dc_type == DC_TYPE_EN5152B ||	\
 	 x->dc_type == DC_TYPE_AN985)
 
 #define DC_IS_INTEL(x)		(x->dc_type == DC_TYPE_21143)
@@ -855,6 +857,13 @@
  */
 #define DC_DEVICEID_EN1217	0x1217
 #define DC_DEVICEID_EN2242	0x1216
+#define DC_DEVICEID_EN5251B	0x1216
+
+/*
+ * The Accton EN5251B is sold as the Siemens Speedstream SS1020.
+ * The EN5251B seems to be a clone of the ADMtek 983 or 983B
+ */
+#define DC_REVISION_EN5251B	0x11  /* ASSUMING that EN2242's revision differs */
 
 /*
  * Conexant vendor ID.
Index: if_dc.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.9.2.33
diff -u -r1.9.2.33 if_dc.c
--- if_dc.c	2002/02/26 04:21:30	1.9.2.33
+++ if_dc.c	2002/03/01 04:21:42
@@ -183,6 +183,8 @@
 		"Accton EN1217 10/100BaseTX" },
 	{ DC_VENDORID_ACCTON, DC_DEVICEID_EN2242,
 		"Accton EN2242 MiniPCI 10/100BaseTX" },
+	{ DC_VENDORID_ACCTON, DC_DEVICEID_EN5251B,
+		"Siemens SpeedStream SS1020 10/100BaseTX" },
 	{ DC_VENDORID_CONEXANT, DC_DEVICEID_RS7112,
 		"Conexant LANfinity MiniPCI 10/100BaseTX" },
 	{ 0, 0, NULL }
@@ -1438,6 +1440,9 @@
 			if (t->dc_did == DC_DEVICEID_DM9102 &&
 			    rev >= DC_REVISION_DM9102A)
 				t++;
+			if (t->dc_did == DC_DEVICEID_EN2242 &&
+			    rev >= DC_REVISION_EN5251B)
+				t++;
 			return(t);
 		}
 		t++;
@@ -1773,8 +1778,17 @@
 		sc->dc_flags |= DC_TX_ADMTEK_WAR;
 		sc->dc_pmode = DC_PMODE_MII;
 		break;
+	case DC_DEVICEID_EN2242:     /* and  DC_DEVICEID_EN5251B:  */
+		if (revision < DC_REVISION_EN5251B) {
+			sc->dc_type = DC_TYPE_AN985;
+		}  else {
+			sc->dc_type = DC_TYPE_EN5152B;
+		}
+		sc->dc_flags |= DC_TX_USE_TX_INTR;
+		sc->dc_flags |= DC_TX_ADMTEK_WAR;
+		sc->dc_pmode = DC_PMODE_MII;
+		break;
 	case DC_DEVICEID_AN985:
-	case DC_DEVICEID_EN2242:
 		sc->dc_type = DC_TYPE_AN985;
 		sc->dc_flags |= DC_TX_USE_TX_INTR;
 		sc->dc_flags |= DC_TX_ADMTEK_WAR;
@@ -1901,6 +1915,7 @@
 		break;
 	case DC_TYPE_AL981:
 	case DC_TYPE_AN985:
+	case DC_TYPE_EN5152B:
 		dc_read_eeprom(sc, (caddr_t)&eaddr, DC_AL_EE_NODEADDR, 3, 0);
 		break;
 	case DC_TYPE_CONEXANT:


>Release-Note:
>Audit-Trail:

From: John Baldwin <jhb@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org, tstockwell@visi.com
Cc:  
Subject: Re: kern/35482: dc driver uses wrong case to read MAC from eeprom.
Date: Mon, 16 Sep 2002 13:30:58 -0400 (EDT)

 I just went out and bought a SppedStream 1012 (it's the cardbus
 version of the 1020 AFAICT) and it read the right MAC address
 (verified by sticker on the card) just fine w/o needing this
 patch.  What MAC address do you get with this patch and what
 address w/o this patch?
 
 cardbus0: Expecting link target, got 0x59
 cardbus0: Resource not specified in CIS: id=10, size=100
 cardbus0: Resource not specified in CIS: id=14, size=400
 dc0: <Accton EN2242 MiniPCI 10/100BaseTX> port 0x1100-0x11ff mem 0x88002000-0x88
 0023ff irq 11 at device 0.0 on cardbus0
 dc0: Ethernet address: 00:30:f1:34:3a:b2
 miibus0: <MII bus> on dc0
 ukphy0: <Generic IEEE 802.3u media interface> on miibus0
 ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 
 -- 
 
 John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

From: "Ted Stockwell" <tstockwell@mesabi-tech.com>
To: "John Baldwin" <jhb@FreeBSD.org>,
	<freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: kern/35482: dc driver uses wrong case to read MAC from eeprom.
Date: Mon, 16 Sep 2002 15:37:12 -0500

 From: "John Baldwin" <jhb@FreeBSD.org>
 To: <freebsd-gnats-submit@FreeBSD.org>; <tstockwell@visi.com>
 > I just went out and bought a SppedStream 1012 (it's the cardbus
 > version of the 1020 AFAICT) and it read the right MAC address
 > (verified by sticker on the card) just fine w/o needing this
 > patch.  What MAC address do you get with this patch and what
 > address w/o this patch?
 >=20
 > cardbus0: Expecting link target, got 0x59
 > cardbus0: Resource not specified in CIS: id=3D10, size=3D100
 > cardbus0: Resource not specified in CIS: id=3D14, size=3D400
 > dc0: <Accton EN2242 MiniPCI 10/100BaseTX> port 0x1100-0x11ff mem =
 0x88002000-0x88
 > 0023ff irq 11 at device 0.0 on cardbus0
 > dc0: Ethernet address: 00:30:f1:34:3a:b2
 > miibus0: <MII bus> on dc0
 > ukphy0: <Generic IEEE 802.3u media interface> on miibus0
 > ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 >=20
 > John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
 > "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
 
 The hardware must be a little different.
 
 Testing two different SpeedStream 1020 cards, without my fix, the MAC=20
 address comes up as: "08:00:08:00:08:00" on both cards.
 
 With the fix the MAC addresses come up as:
 "00:30:f1:2d:f5:a1" and "00:30:f1:10:b7:a8". =20
 The vendor id of "00-30-f1" is correct for Accton Technologies.
 
 In if_dc.c's dc_eeprom_putbyte(), there is a special case for the
 AN985 (DC_IS_CENTAUR).  The comment states that:
 "The AN985 has a 93C66 EEPROM on it instead of a 93C46.  It uses=20
 a different bit sequence for specifying the "read" opcode."
 
 The SpeedStream 1020 behaves like a AN985 clone, but has a=20
 93c46 EEPROM.  So, going down the CENTAUR special case=20
 causes it to read the eeprom incorrectly.
 
 One resource I found on the net suggested that the EN5251 was=20
 really a clone of the ADMtek 983. I do not know how the 983=20
 differs from the the 985 or 981, which are explicitly supported in=20
 by the dc driver.
 
 One point about this code that merits review is the use of the
 DC_IS_CENTAUR() macro. Should the DC_IS_CENTAUR=20
 be used in dc_eeprom_putbyte(), in which case the EN5251B=20
 is not a CENTAUR? Or, should the test in dc_eeprom_putbyte()=20
 test explicitly for the 985, in which case the new DC_TYPE_EN5152B=20
 type should be added to DC_IS_CENTAUR?
 
 my notes can be found at:
 http://www.visi.com/~tstockwell/SS1020.html
 
 --
 Ted Stockwell,   tstockwell@mesabi-tech.com
Responsible-Changed-From-To: freebsd-bugs->mbr 
Responsible-Changed-By: mbr 
Responsible-Changed-When: Thu Jan 30 15:45:43 PST 2003 
Responsible-Changed-Why:  
I'll look at this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35482 
State-Changed-From-To: open->analyzed 
State-Changed-By: mbr 
State-Changed-When: Wed Feb 12 14:57:23 PST 2003 
State-Changed-Why:  
A fix has been committed to both STABLE and CURRENT. 
I'll close this PR soon if you agree. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35482 
State-Changed-From-To: analyzed->closed 
State-Changed-By: mbr 
State-Changed-When: Wed Feb 19 16:35:17 PST 2003 
State-Changed-Why:  
Feedback timeout. Others have reported that this bug got 
fixed with my commit. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=35482 
>Unformatted:
