NetBSD Problem Report #46961

From ryo_on@yk.rim.or.jp  Sun Sep 16 00:48:05 2012
Return-Path: <ryo_on@yk.rim.or.jp>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id C3BE163BA3B
	for <gnats-bugs@gnats.netbsd.org>; Sun, 16 Sep 2012 00:48:05 +0000 (UTC)
Message-Id: <20120916004805.C3BE163BA3B@www.NetBSD.org>
Date: Sun, 16 Sep 2012 00:48:05 +0000 (UTC)
From: ryoon@NetBSD.org
Reply-To: ryoon@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: Please support BCM57762 Ethernet arapter (Apple's Thunderbolt Ethernet Adapter)
X-Send-Pr-Version: 3.95

>Number:         46961
>Category:       kern
>Synopsis:       Please support BCM57762 Ethernet arapter (Apple's Thunderbolt Ethernet Adapter)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tsutsui
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 16 00:50:01 +0000 2012
>Closed-Date:    Fri Sep 28 12:42:47 +0000 2012
>Last-Modified:  Mon Aug 26 04:05:00 +0000 2013
>Originator:     Ryo ONODERA
>Release:        NetBSD 6.99.11
>Organization:

>Environment:


System: NetBSD tellurium.elements.tetera.org 6.99.11 NetBSD 6.99.11 (NODKWEDGE) #42: Sun Sep 16 09:31:57 JST 2012 root@tellurium.elements.tetera.org:/usr/obj/sys/arch/amd64/compile/NODKWEDGE amd64
Architecture: x86_64
Machine: amd64
>Description:
Apple's Thunderbolt to Gigabit Ethernet Adapter,
http://store.apple.com/us/product/MD463ZM/A/thunderbolt-to-gigabit-ethernet-adapter ,
is not supported for NetBSD current.
Please support it.
With my patches, I have gotten the following dmesg and ifconfig output.

dmesg:

bge0 at pci8 dev 0 function 0: Broadcom BCM57762 Gigabit Ethernet
bge0: interrupting at ioapic0 pin 19
bge0: ASIC unknown BCM57766 (0x57766000), Ethernet address 40:6c:8f:58:6c:c5
bge0: setting short Tx thresholds
brgphy0 at bge0 phy 1: BCM57765 1000BASE-T media interface, rev. 0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto


ifconfig output:

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=0
        address: 40:6c:8f:58:6c:c5
        media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpause)
        status: active
        inet 192.168.81.9 netmask 0xffffff00 broadcast 192.168.81.255
        inet6 fe80::426c:8fff:fe58:6cc5%bge0 prefixlen 64 scopeid 0x1


>How-To-Repeat:
Insert Thunderbolt to Gigabit Ethernet Adapter to Apple's machine,
for example Macbook Air, and reboot.

>Fix:

Index: net/if_ether.h
===================================================================
RCS file: /cvsroot/src/sys/net/if_ether.h,v
retrieving revision 1.58
diff -u -r1.58 if_ether.h
--- net/if_ether.h	19 May 2010 20:41:59 -0000	1.58
+++ net/if_ether.h	16 Sep 2012 00:45:23 -0000
@@ -51,6 +51,7 @@
 #define	ETHER_MIN_LEN	64	/* minimum frame length, including CRC */
 #define	ETHER_MAX_LEN	1518	/* maximum frame length, including CRC */
 #define	ETHER_MAX_LEN_JUMBO 9018 /* maximum jumbo frame len, including CRC */
+#define ETHER_MAX_DIX_LEN	1536	/* Maximum DIX frame length */

 /*
  * Some Ethernet extensions.
Index: dev/pci/if_bge.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.201
diff -u -r1.201 if_bge.c
--- dev/pci/if_bge.c	22 Jul 2012 14:33:01 -0000	1.201
+++ dev/pci/if_bge.c	16 Sep 2012 00:45:23 -0000
@@ -564,6 +564,10 @@
 	  "Broadcom BCM57761 Fast Ethernet",
 	  },
 	{ PCI_VENDOR_BROADCOM,
+	  PCI_PRODUCT_BROADCOM_BCM57762,
+	  "Broadcom BCM57762 Gigabit Ethernet",
+	  },
+	{ PCI_VENDOR_BROADCOM,
 	  PCI_PRODUCT_BROADCOM_BCM57765,
 	  "Broadcom BCM57765 Fast Ethernet",
 	  },
@@ -728,6 +732,7 @@
 	{ BGE_ASICREV_BCM57780, "unknown BCM57780" },
 	{ BGE_ASICREV_BCM5717, "unknown BCM5717" },
 	{ BGE_ASICREV_BCM57765, "unknown BCM57765" },
+	{ BGE_ASICREV_BCM57766, "unknown BCM57766" },

 	{ 0, NULL }
 };
@@ -1969,7 +1974,23 @@
 #else

 	/* new broadcom docs strongly recommend these: */
-	if (!BGE_IS_5705_PLUS(sc)) {
+	if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766) {
+		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
+		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x2a);
+		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0xa0);
+	} else if (BGE_IS_5705_PLUS(sc)) {
+		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
+
+		if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5906) {
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x04);
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x10);
+		} else {
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
+		}
+	} else if (!BGE_IS_5705_PLUS(sc)) {
 		if (ifp->if_mtu > ETHER_MAX_LEN) {
 			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x50);
 			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x20);
@@ -1979,14 +2000,10 @@
 			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 152);
 			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 380);
 		}
-	} else if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5906) {
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x04);
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x10);
 	} else {
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
-		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
+			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
 	}
 #endif

@@ -2031,7 +2048,12 @@
 	/* Step 41: Initialize the standard RX ring control block */
 	rcb = &sc->bge_rdata->bge_info.bge_std_rx_rcb;
 	BGE_HOSTADDR(rcb->bge_hostaddr, BGE_RING_DMA_ADDR(sc, bge_rx_std_ring));
-	if (BGE_IS_5705_PLUS(sc))
+	if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
+		rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
+					(ETHER_MAX_DIX_LEN << 2));
+	else if (BGE_IS_5705_PLUS(sc))
 		rcb->bge_maxlen_flags = BGE_RCB_MAXLEN_FLAGS(512, 0);
 	else
 		rcb->bge_maxlen_flags =
@@ -2097,7 +2119,8 @@
 	CSR_WRITE_4(sc, BGE_RBDI_JUMBO_REPL_THRESH, BGE_JUMBO_RX_RING_CNT / 8);

 	if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
-	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765) {
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766) {
 		CSR_WRITE_4(sc, BGE_STD_REPL_LWM, 4);
 		CSR_WRITE_4(sc, BGE_JUMBO_REPL_LWM, 4);
 	}
@@ -2603,6 +2626,7 @@
 			sc->bge_chipid = pci_conf_read(pc, pa->pa_tag,
 			    BGE_PCI_GEN2_PRODID_ASICREV);
 		else if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_BROADCOM_BCM57761 ||
+			 PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_BROADCOM_BCM57762 ||
 			 PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_BROADCOM_BCM57765 ||
 			 PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_BROADCOM_BCM57781 ||
 			 PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_BROADCOM_BCM57785 ||
@@ -2651,6 +2675,7 @@
 	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5785 ||
 	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5787 ||
 	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766 ||
 	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57780)
 		sc->bge_flags |= BGE_5755_PLUS;

@@ -2751,6 +2776,7 @@
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM5717 &&
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM5785 &&
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57765 &&
+	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57766 &&
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57780) {
 		if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5755 ||
 		    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5761 ||
@@ -2904,10 +2930,14 @@
 			    "setting short Tx thresholds\n");
 	}

-	if (BGE_IS_5705_PLUS(sc))
-		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
-	else
+
+	if (BGE_IS_5700_FAMILY(sc) ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
+	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
+	else
+		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;

 	/* Set up ifnet structure */
 	ifp = &sc->ethercom.ec_if;
@@ -3297,7 +3327,8 @@
 	    sc->bge_chipid != BGE_CHIPID_BCM5750_A0 &&
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM5717 &&
 	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM5785 &&
-	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57765) {
+	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57765 &&
+	    BGE_ASICREV(sc->bge_chipid) != BGE_ASICREV_BCM57766) {
 		uint32_t v;

 		/* Enable PCI Express bug fix */
Index: dev/pci/if_bgereg.h
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.56
diff -u -r1.56 if_bgereg.h
--- dev/pci/if_bgereg.h	3 Feb 2010 15:36:36 -0000	1.56
+++ dev/pci/if_bgereg.h	16 Sep 2012 00:45:24 -0000
@@ -318,6 +318,7 @@
 #define BGE_CHIPID_BCM5787_A2		0xb002
 #define BGE_CHIPID_BCM5906_A1		0xc001
 #define BGE_CHIPID_BCM5906_A2		0xc002
+#define BGE_CHIPID_BCM57762		0x57766000
 #define BGE_CHIPID_BCM57780_A0		0x57780000
 #define BGE_CHIPID_BCM57780_A1		0x57780001

@@ -344,6 +345,7 @@
 #define BGE_ASICREV_BCM57780		0x57780
 #define BGE_ASICREV_BCM5717		0x5717
 #define BGE_ASICREV_BCM57765		0x57785
+#define BGE_ASICREV_BCM57766		0x57766

 /* chip revisions */
 #define BGE_CHIPREV(x)			((x) >> 8)
Index: dev/pci/pcidevs
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1133
diff -u -r1.1133 pcidevs
--- dev/pci/pcidevs	13 Sep 2012 12:11:06 -0000	1.1133
+++ dev/pci/pcidevs	16 Sep 2012 00:45:24 -0000
@@ -1592,6 +1592,7 @@
 product BROADCOM BCM5787F	0x167f	BCM5787F 10/100 Ethernet
 product BROADCOM BCM5761E	0x1680	BCM5761E 10/100/1000 Ethernet
 product BROADCOM BCM5761	0x1681	BCM5761 10/100/1000 Ethernet
+product BROADCOM BCM57762	0x1682	BCM57762 Gigabit Ethernet
 product BROADCOM BCM5764	0x1684	BCM5764 NetXtreme 1000baseT Ethernet
 product BROADCOM BCM5761S	0x1688	BCM5761S 10/100/1000 Ethernet
 product BROADCOM BCM5761SE	0x1689	BCM5761SE 10/100/1000 Ethernet


>Release-Note:

>Audit-Trail:
From: Ryo ONODERA <ryo_on@yk.rim.or.jp>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple's
 Thunderbolt Ethernet Adapter)
Date: Sun, 16 Sep 2012 09:51:33 +0900 (JST)

 I have forgotten to mention the origin of the patch.
 These patches are from OpenBSD' bge and DragonFly's bnx.


From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple's Thunderbolt
	 Ethernet Adapter)
Date: Sun, 16 Sep 2012 19:21:46 +0900

 > --- net/if_ether.h	19 May 2010 20:41:59 -0000	1.58
 > +++ net/if_ether.h	16 Sep 2012 00:45:23 -0000

 > +#define ETHER_MAX_DIX_LEN	1536	/* Maximum DIX frame length */

 What does the "Maximum DIX frame length" mean?

 With a quick glance, OpenBSD's cvs log doesn't mention about it
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/if_ether.h#rev1.34
 and I can't find description that mentions 1536 bytes around DIX Ethernet.

 If there is no specification about the value, it's better
 to add local macro into if_bge.c rather than MI if_ether.h.

 > --- dev/pci/if_bge.c	22 Jul 2012 14:33:01 -0000	1.201
 > +++ dev/pci/if_bge.c	16 Sep 2012 00:45:23 -0000

 > @@ -564,6 +564,10 @@
 >  	"Broadcom BCM57761 Fast Ethernet",
 >  	  },
 >  	{ PCI_VENDOR_BROADCOM,
 > +	  PCI_PRODUCT_BROADCOM_BCM57762,
 > +	  "Broadcom BCM57762 Gigabit Ethernet",
 > +	  },
 > +	{ PCI_VENDOR_BROADCOM,
 >  	  PCI_PRODUCT_BROADCOM_BCM57765,
 >  	  "Broadcom BCM57765 Fast Ethernet",
 >  	},
 > @@ -728,6 +732,7 @@
 >  	{ BGE_ASICREV_BCM57780, "unknown BCM57780" },
 >  	{ BGE_ASICREV_BCM5717, "unknown BCM5717" },
 >  	{ BGE_ASICREV_BCM57765, "unknown BCM57765" },
 > +	{ BGE_ASICREV_BCM57766, "unknown BCM57766" },
 >  
 >  	{ 0, NULL }
 >  };

 Your bge is BCM57762, but has BCM57766 ASICREV?
 Where does the name come from?

 Even if the actual value of BGE_ASICREV_BCM57766 is "0x57766",
 it's less confusing to define it as "BGE_ASICREV_BCM57762"
 for readers if it's actually returned by 57762.
 (existing "BGE_ASICREV_BCM57765" is "0x57785" anyway)

 > @@ -1979,14 +2000,10 @@

 >  	} else {
 > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
 > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
 > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
 > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
 > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
 > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
 >  	}
 >  #endif

 Wrong and unnecessary indent changes?


 > @@ -2031,7 +2048,12 @@
 >  	/* Step 41: Initialize the standard RX ring control block */
 >  	rcb = &sc->bge_rdata->bge_info.bge_std_rx_rcb;
 >  	BGE_HOSTADDR(rcb->bge_hostaddr, BGE_RING_DMA_ADDR(sc, bge_rx_std_ring));
 > -	if (BGE_IS_5705_PLUS(sc))
 > +	if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 > +		rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
 > +					(ETHER_MAX_DIX_LEN << 2));
 > +	else if (BGE_IS_5705_PLUS(sc))
 >  		rcb->bge_maxlen_flags = BGE_RCB_MAXLEN_FLAGS(512, 0);
 >  	else
 >  		rcb->bge_maxlen_flags =

 Doesn't your 57762 work without this (ETHER_MAX_DIX_LEN << 2) change?

 OpenBSD log says it was taken from Linux driver,
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_bge.c#rev1.28
 but probably we should check specification of the
 BGE_RX_STD_RCB_MAXLEN_FLAGS register...

 > @@ -2904,10 +2930,14 @@
 >  			    "setting short Tx thresholds\n");
 >  	}
 >  
 > -	if (BGE_IS_5705_PLUS(sc))
 > -		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 > -	else
 > +
 > +	if (BGE_IS_5700_FAMILY(sc) ||
 > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >  		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
 > +	else
 > +		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 >  
 >  	/* Set up ifnet structure */
 >  	ifp = &sc->ethercom.ec_if;

 It could be problematic (i.e. hard to confirm) to change default
 sc->bge_return_ring_cnt value.

 How about this one?
 ---
 	if (BGE_IS_5705_PLUS(sc) {
 		if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 		    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 		    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 			sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
 		else
 			sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 	} else
 		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
 ---

 Izumi Tsutsui

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple's ThunderboltEthernet
	 Adapter)
Date: Sun, 16 Sep 2012 19:51:45 +0900

 I wrote:

 >  Doesn't your 57762 work without this (ETHER_MAX_DIX_LEN << 2) change?
 >  
 >  OpenBSD log says it was taken from Linux driver,
 >  http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_bge.c#rev1.28
 >  but probably we should check specification of the
 >  BGE_RX_STD_RCB_MAXLEN_FLAGS register...

 Okay, there is a Programmer's Guide of 57765/57762 in
 Broadcom's "Ethernet NIC Open Source Developer Resources" page:
 http://ja.broadcom.com/support/ethernet_nic/open_source.php

 It says bits 15:2 in the "Receive Producer Length/Flags Register"
 means "Maximum Ethernet Frame Length" and the description also says

  "specifies the maximum size of an Ethernet frame plus VLAN tag"

 so probably

 >>	rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512,
 >>	    ((ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) << 2));

 is enough, rather than indroducing unknown ETHER_MAX_DIX_LEN.

 ---
 Izumi Tsutsui

From: Ryo ONODERA <ryo_on@yk.rim.or.jp>
To: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Cc: 
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple's
 Thunderbolt Ethernet Adapter)
Date: Sun, 16 Sep 2012 22:52:03 +0900 (JST)

 Hi,

 Thanks for your review!
 I have add the replies below.

 I have update my patches.
 And I have forgotten to include PHY part.

 Please see new patches.
 http://www.netbsd.org/~ryoon/120916a-bcm57762.diff

 From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, Date: Sun, 16 Sep 2012 10:25:02 +0000 (UTC)

 > The following reply was made to PR kern/46961; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@NetBSD.org, tsutsui@ceres.dti.ne.jp
 > Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple's Thunderbolt
 > 	 Ethernet Adapter)
 > Date: Sun, 16 Sep 2012 19:21:46 +0900
 > 
 >  > --- net/if_ether.h	19 May 2010 20:41:59 -0000	1.58
 >  > +++ net/if_ether.h	16 Sep 2012 00:45:23 -0000
 >  
 >  > +#define ETHER_MAX_DIX_LEN	1536	/* Maximum DIX frame length */
 >  
 >  What does the "Maximum DIX frame length" mean?
 >  
 >  With a quick glance, OpenBSD's cvs log doesn't mention about it
 >  http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/if_ether.h#rev1.34
 >  and I can't find description that mentions 1536 bytes around DIX Ethernet.
 >  
 >  If there is no specification about the value, it's better
 >  to add local macro into if_bge.c rather than MI if_ether.h.

 I think DIX Ethernet's max length is 1526.
 I have no idea about 1536.

 Anyway I will make ETHER_MAX_DIX_LEN bge local.

 >  > --- dev/pci/if_bge.c	22 Jul 2012 14:33:01 -0000	1.201
 >  > +++ dev/pci/if_bge.c	16 Sep 2012 00:45:23 -0000
 >  
 >  > @@ -564,6 +564,10 @@
 >  >  	"Broadcom BCM57761 Fast Ethernet",
 >  >  	  },
 >  >  	{ PCI_VENDOR_BROADCOM,
 >  > +	  PCI_PRODUCT_BROADCOM_BCM57762,
 >  > +	  "Broadcom BCM57762 Gigabit Ethernet",
 >  > +	  },
 >  > +	{ PCI_VENDOR_BROADCOM,
 >  >  	  PCI_PRODUCT_BROADCOM_BCM57765,
 >  >  	  "Broadcom BCM57765 Fast Ethernet",
 >  >  	},
 >  > @@ -728,6 +732,7 @@
 >  >  	{ BGE_ASICREV_BCM57780, "unknown BCM57780" },
 >  >  	{ BGE_ASICREV_BCM5717, "unknown BCM5717" },
 >  >  	{ BGE_ASICREV_BCM57765, "unknown BCM57765" },
 >  > +	{ BGE_ASICREV_BCM57766, "unknown BCM57766" },
 >  >  
 >  >  	{ 0, NULL }
 >  >  };
 >  
 >  Your bge is BCM57762, but has BCM57766 ASICREV?
 >  Where does the name come from?
 >  
 >  Even if the actual value of BGE_ASICREV_BCM57766 is "0x57766",
 >  it's less confusing to define it as "BGE_ASICREV_BCM57762"
 >  for readers if it's actually returned by 57762.

 Linux's tg3 identifies 0x57766 as ASIC_REV_57766.
 See http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/tg3.c#L13653 .

 >  (existing "BGE_ASICREV_BCM57765" is "0x57785" anyway)

 In Linux's tg3 0x57785 is ASIC_REV_57765.

 In my opinion, 0x57766 should be BGE_ASICREV_57766, due to consistency
 between OSes.


 >  > @@ -1979,14 +2000,10 @@
 >  
 >  >  	} else {
 >  > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
 >  > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
 >  > -		CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
 >  > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
 >  > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x10);
 >  > +			CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_HIWAT, 0x60);
 >  >  	}
 >  >  #endif
 >  
 >  Wrong and unnecessary indent changes?

 Yes.


 >  > @@ -2031,7 +2048,12 @@
 >  >  	/* Step 41: Initialize the standard RX ring control block */
 >  >  	rcb = &sc->bge_rdata->bge_info.bge_std_rx_rcb;
 >  >  	BGE_HOSTADDR(rcb->bge_hostaddr, BGE_RING_DMA_ADDR(sc, bge_rx_std_ring));
 >  > -	if (BGE_IS_5705_PLUS(sc))
 >  > +	if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 >  > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 >  > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >  > +		rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
 >  > +					(ETHER_MAX_DIX_LEN << 2));
 >  > +	else if (BGE_IS_5705_PLUS(sc))
 >  >  		rcb->bge_maxlen_flags = BGE_RCB_MAXLEN_FLAGS(512, 0);
 >  >  	else
 >  >  		rcb->bge_maxlen_flags =
 >  
 >  Doesn't your 57762 work without this (ETHER_MAX_DIX_LEN << 2) change?

 ETHER_MAX_DIX_LEN << 2 is essential.
 But 1626 << 2 is also acceptable.

 >  OpenBSD log says it was taken from Linux driver,
 >  http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_bge.c#rev1.28
 >  but probably we should check specification of the
 >  BGE_RX_STD_RCB_MAXLEN_FLAGS register...
 >  
 >  > @@ -2904,10 +2930,14 @@
 >  >  			    "setting short Tx thresholds\n");
 >  >  	}
 >  >  
 >  > -	if (BGE_IS_5705_PLUS(sc))
 >  > -		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 >  > -	else
 >  > +
 >  > +	if (BGE_IS_5700_FAMILY(sc) ||
 >  > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 >  > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 >  > +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >  >  		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
 >  > +	else
 >  > +		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 >  >  
 >  >  	/* Set up ifnet structure */
 >  >  	ifp = &sc->ethercom.ec_if;
 >  
 >  It could be problematic (i.e. hard to confirm) to change default
 >  sc->bge_return_ring_cnt value.
 >  
 >  How about this one?
 >  ---
 >  	if (BGE_IS_5705_PLUS(sc) {
 >  		if (BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM5717 ||
 >  		    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57765 ||
 >  		    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >  			sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;
 >  		else
 >  			sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT_5705;
 >  	} else
 >  		sc->bge_return_ring_cnt = BGE_RETURN_RING_CNT;

 This works well.

 >  ---
 >  
 >  Izumi Tsutsui
 >  
 > 
 > 

 --
 Ryo ONODERA // ryo_on@yk.rim.or.jp
 PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3


From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple'sThunderbolt
	 Ethernet Adapter)
Date: Mon, 17 Sep 2012 00:13:24 +0900

 >  Please see new patches.
 >  http://www.netbsd.org/~ryoon/120916a-bcm57762.diff
  :
 >  I think DIX Ethernet's max length is 1526.
 >  I have no idea about 1536.
 >  
 >  Anyway I will make ETHER_MAX_DIX_LEN bge local.

 I don't think we support any DIX Ethernet specific features
 and the possible maximum packet length is VLAN one
 (i.e. ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN (1518 + 4) bytes),
 so it would be better to define and use ETHER_VLAN_MAX_LEN (or so),
 even if it's defined in if_bgereg.h locally.

 >> @@ -2383,3 +2385,10 @@
   :
 >> +
 >> +/*
 >> + * Maximum DIX frame length
 >> + * In OpenBSD's sys/netinet/if_ether.h, this is 1536,
 >> + * but it should be 1526.
 >> + */
 >> +#define ETHER_MAX_DIX_LEN	1526

 if_bgereg.h already has local packet lenghth definitions
 around lines 2330-2335, so it's also better to put a new local
 value in the same place.

 >> +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >> +		rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
 >> +					(ETHER_MAX_DIX_LEN << 2));
 >> +	else if (BGE_IS_5705_PLUS(sc))

 BGE_RCB_MAXLEN_FLAGS() macro is defined as following in if_bgereg.h:

 >> #define BGE_RCB_MAXLEN_FLAGS(maxlen, flags)	((maxlen) << 16 | (flags))

 so it's consistent to put the packet length value into the macro, i.e.
 	rcb->bge_maxlen_flags =
 	    BGE_RCB_MAXLEN_FLAGS(512, ETHER_VLAN_MAX_LEN << 2);

 >  Linux's tg3 identifies 0x57766 as ASIC_REV_57766.
 >  See http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/tg3.c#L13653 .
 >  
 >  >  (existing "BGE_ASICREV_BCM57765" is "0x57785" anyway)
 >  
 >  In Linux's tg3 0x57785 is ASIC_REV_57765.
 >  
 >  In my opinion, 0x57766 should be BGE_ASICREV_57766, due to consistency
 >  between OSes.

 I see, then it's fine.

 ---
 Izumi Tsutsui

From: Ryo ONODERA <ryo_on@yk.rim.or.jp>
To: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Cc: 
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter
 (Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 04:41:25 +0900 (JST)

 Hi,

 Thank you.

 I have updated the patches.
 http://www.netbsd.org/~ryoon/120916b-bcm57762.diff

 From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>, Date: Sun, 16 Sep 2012 15:15:05 +0000 (UTC)

 > The following reply was made to PR kern/46961; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@NetBSD.org, tsutsui@ceres.dti.ne.jp
 > Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter (Apple'sThunderbolt
 > 	 Ethernet Adapter)
 > Date: Mon, 17 Sep 2012 00:13:24 +0900
 > 
 >  >  Please see new patches.
 >  >  http://www.netbsd.org/~ryoon/120916a-bcm57762.diff
 >   :
 >  >  I think DIX Ethernet's max length is 1526.
 >  >  I have no idea about 1536.
 >  >  
 >  >  Anyway I will make ETHER_MAX_DIX_LEN bge local.
 >  
 >  I don't think we support any DIX Ethernet specific features
 >  and the possible maximum packet length is VLAN one
 >  (i.e. ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN (1518 + 4) bytes),
 >  so it would be better to define and use ETHER_VLAN_MAX_LEN (or so),
 >  even if it's defined in if_bgereg.h locally.
 >  
 >  >> @@ -2383,3 +2385,10 @@
 >    :
 >  >> +
 >  >> +/*
 >  >> + * Maximum DIX frame length
 >  >> + * In OpenBSD's sys/netinet/if_ether.h, this is 1536,
 >  >> + * but it should be 1526.
 >  >> + */
 >  >> +#define ETHER_MAX_DIX_LEN	1526
 >  
 >  if_bgereg.h already has local packet lenghth definitions
 >  around lines 2330-2335, so it's also better to put a new local
 >  value in the same place.

 I see.
 I have defined ETHER_VLAN_MAX_LEN in the suggested place of if_bgereg.h.
 It works.

 >  >> +	    BGE_ASICREV(sc->bge_chipid) == BGE_ASICREV_BCM57766)
 >  >> +		rcb->bge_maxlen_flags = (BGE_RCB_MAXLEN_FLAGS(512, 0) |
 >  >> +					(ETHER_MAX_DIX_LEN << 2));
 >  >> +	else if (BGE_IS_5705_PLUS(sc))
 >  
 >  BGE_RCB_MAXLEN_FLAGS() macro is defined as following in if_bgereg.h:
 >  
 >  >> #define BGE_RCB_MAXLEN_FLAGS(maxlen, flags)	((maxlen) << 16 | (flags))
 >  
 >  so it's consistent to put the packet length value into the macro, i.e.
 >  	rcb->bge_maxlen_flags =
 >  	    BGE_RCB_MAXLEN_FLAGS(512, ETHER_VLAN_MAX_LEN << 2);

 I understand.
 I have used this.


 >  >  Linux's tg3 identifies 0x57766 as ASIC_REV_57766.
 >  >  See http://lxr.free-electrons.com/source/drivers/net/ethernet/broadcom/tg3.c#L13653 .
 >  >  
 >  >  >  (existing "BGE_ASICREV_BCM57765" is "0x57785" anyway)
 >  >  
 >  >  In Linux's tg3 0x57785 is ASIC_REV_57765.
 >  >  
 >  >  In my opinion, 0x57766 should be BGE_ASICREV_57766, due to consistency
 >  >  between OSes.
 >  
 >  I see, then it's fine.
 >  
 >  ---
 >  Izumi Tsutsui
 >  
 > 
 > 

 --
 Ryo ONODERA // ryo_on@yk.rim.or.jp
 PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3


From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: ryo_on@yk.rim.or.jp
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter)
Date: Mon, 17 Sep 2012 13:41:25 +0900

 > http://www.netbsd.org/~ryoon/120916b-bcm57762.diff
  :
 > I have defined ETHER_VLAN_MAX_LEN in the suggested place of if_bgereg.h.
 > It works.

 I notice original FreeBSD's bge driver uses BGE_MAX_FRAMELEN for
 BGE_RX_STD_RCB_MAXLEN_FLAGS register, and we also use it in
 older !BGE_IS_5705_PLUS(sc) case.

 The value is used to specify "Maximum Ethernet Frame Length"
 for RX descriptors, so 1536 bytes should also work and using it
 as a bge's magic number would be better to avoid divergence
 from other OSes.

 In our if_bgereg.h, BGE_MAX_FRAMELEN is defined as following:

 > #define BGE_MAX_FRAMELEN	(ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN)

 but this seems wrong because ETHER_MAX_LEN already includes header
 and CRC length, and the original FreeBSD's bge just defines it as "1536"
 (though ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN is also 1536),
 so I'll change BGE_MAX_FRAMELEN definition.

 I'll integrate your patch (with the above change) later. Thanks.
 ---
 Izumi Tsutsui

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 07:57:39 +0100

 On Mon, Sep 17, 2012 at 04:45:02AM +0000, Izumi Tsutsui wrote:
 > The following reply was made to PR kern/46961; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
 > To: ryo_on@yk.rim.or.jp
 > Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
 > Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
 > 	 Ethernet Adapter)
 > Date: Mon, 17 Sep 2012 13:41:25 +0900
 > 
 >  > http://www.netbsd.org/~ryoon/120916b-bcm57762.diff
 >   :
 >  > I have defined ETHER_VLAN_MAX_LEN in the suggested place of if_bgereg.h.
 >  > It works.
 >  
 >  I notice original FreeBSD's bge driver uses BGE_MAX_FRAMELEN for
 >  BGE_RX_STD_RCB_MAXLEN_FLAGS register, and we also use it in
 >  older !BGE_IS_5705_PLUS(sc) case.
 >  
 >  The value is used to specify "Maximum Ethernet Frame Length"
 >  for RX descriptors, so 1536 bytes should also work and using it
 >  as a bge's magic number would be better to avoid divergence
 >  from other OSes.
 >  
 >  In our if_bgereg.h, BGE_MAX_FRAMELEN is defined as following:
 >  
 >  > #define BGE_MAX_FRAMELEN	(ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN)
 >  
 >  but this seems wrong because ETHER_MAX_LEN already includes header
 >  and CRC length, and the original FreeBSD's bge just defines it as "1536"
 >  (though ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN is also 1536),
 >  so I'll change BGE_MAX_FRAMELEN definition.

 There are all sorts of reasons why an rx buffer size of 1536 is a good idea.
 Mostly because it is a nice round number!
 It might even be that the register it gets written to has non-writeable
 low bits.
 Allowing 'slightly overlong' packets is useful for certain protocols,
 I'm sure I remember something else, as well as VLAN, extending the
 maximum length.

 Generating 1536 as in BGE_MAX_FRAMELEN above is rather bogus though.
 I also don't really remember DIX meaning anything in particular.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: david@l8s.co.uk
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter)
Date: Mon, 17 Sep 2012 16:38:57 +0900

 david@ wrote:

 >  There are all sorts of reasons why an rx buffer size of 1536 is a good idea.
 >  Mostly because it is a nice round number!

 I don't see any benefits by rounding the number in this case.

 >  It might even be that the register it gets written to has non-writeable
 >  low bits.

 Broadcom's programmer's guide mentions no such "non-writeable low bits".

 >  Allowing 'slightly overlong' packets is useful for certain protocols,
 >  I'm sure I remember something else, as well as VLAN, extending the
 >  maximum length.

 Then shouldn't it be defined in MI sys/net headers?
 Why don't we only have ETHERCAP_VLAN_MTU and ETHERCAP_JUMBO_MTU
 in the capability flag?

 Anyway "syncing with the original FreeBSD's driver" is a good reason
 for me because we no longer have particular maintainers of this driver.
 (and no reason to pull OpenBSD's ETHER_MAX_DIX_LEN macro)

 ---
 Izumi Tsutsui

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/pci
Date: Mon, 17 Sep 2012 11:35:31 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:35:31 UTC 2012

 Modified Files:
 	src/sys/dev/pci: pcidevs

 Log Message:
 Add Broadcom BCM57762 Gigabit Ethernet, per PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1133 -r1.1134 src/sys/dev/pci/pcidevs

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/pci
Date: Mon, 17 Sep 2012 11:38:36 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:38:35 UTC 2012

 Modified Files:
 	src/sys/dev/pci: pcidevs.h pcidevs_data.h

 Log Message:
 Regen from pcidevs rev 1.1134:
 > Add Broadcom BCM57762 Gigabit Ethernet, per PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1126 -r1.1127 src/sys/dev/pci/pcidevs.h
 cvs rdiff -u -r1.1125 -r1.1126 src/sys/dev/pci/pcidevs_data.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/mii
Date: Mon, 17 Sep 2012 11:42:39 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:42:38 UTC 2012

 Modified Files:
 	src/sys/dev/mii: miidevs

 Log Message:
 Add another Broadcom OUI and BCM57765 1000BASE-T media interface.
 Per PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.108 -r1.109 src/sys/dev/mii/miidevs

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/mii
Date: Mon, 17 Sep 2012 11:43:51 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:43:50 UTC 2012

 Modified Files:
 	src/sys/dev/mii: miidevs.h miidevs_data.h

 Log Message:
 Regen from miidevs rev 1.109:
 > Add another Broadcom OUI and BCM57765 1000BASE-T media interface.
 > Per PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.111 -r1.112 src/sys/dev/mii/miidevs.h
 cvs rdiff -u -r1.99 -r1.100 src/sys/dev/mii/miidevs_data.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/mii
Date: Mon, 17 Sep 2012 11:45:56 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:45:56 UTC 2012

 Modified Files:
 	src/sys/dev/mii: brgphy.c

 Log Message:
 Add support for BCM57765.  PR kern/46961


 To generate a diff of this commit:
 cvs rdiff -u -r1.59 -r1.60 src/sys/dev/mii/brgphy.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: src/sys/dev/pci
Date: Mon, 17 Sep 2012 11:54:36 +0000

 Module Name:	src
 Committed By:	tsutsui
 Date:		Mon Sep 17 11:54:36 UTC 2012

 Modified Files:
 	src/sys/dev/pci: if_bge.c if_bgereg.h

 Log Message:
 Add support for BCM57762, found in Apple's Thunderbolt to Gigabit Ethernet
 Adapter.  PR kern/46961 from Ryo ONODERA.

 Also revert weird BGE_MAX_FRAMELEN macro definition to sync its usage
 with the original FreeBSD's bge.


 To generate a diff of this commit:
 cvs rdiff -u -r1.201 -r1.202 src/sys/dev/pci/if_bge.c
 cvs rdiff -u -r1.56 -r1.57 src/sys/dev/pci/if_bgereg.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: kern-bug-people->tsutsui
Responsible-Changed-By: tsutsui@NetBSD.org
Responsible-Changed-When: Mon, 17 Sep 2012 20:58:28 +0900
Responsible-Changed-Why:
as committer


State-Changed-From-To: open->feedback
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Mon, 17 Sep 2012 20:58:28 +0900
State-Changed-Why:
Integrated.

Note I've also changed sc->bge_return_ring_cnt initialization in bge_attach()
to sync with FreeBSD's bge.


From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46961 (Please support BCM57762 Ethernet arapter (Apple's
 Thunderbolt Ethernet Adapter))
Date: Mon, 17 Sep 2012 13:59:09 +0200

 On Mon, Sep 17, 2012 at 11:58:29AM +0000, tsutsui@NetBSD.org wrote:
 > State-Changed-From-To: open->feedback
 > State-Changed-By: tsutsui@NetBSD.org
 > State-Changed-When: Mon, 17 Sep 2012 20:58:28 +0900
 > State-Changed-Why:
 > Integrated.

 Thank you. Can you please update the man page as well?
  Thomas

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: wiz@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961 (Please support BCM57762 Ethernet arapter (Apple'sThunderbolt
	 Ethernet Adapter))
Date: Mon, 17 Sep 2012 21:10:21 +0900

 >  Thank you. Can you please update the man page as well?

 How?

 The man page looks completely out of date and enough to have another PR.

 ---
 Izumi Tsutsui

From: Thomas Klausner <wiz@NetBSD.org>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/46961 (Please support BCM57762 Ethernet arapter
 (Apple'sThunderbolt Ethernet Adapter))
Date: Mon, 17 Sep 2012 14:51:57 +0200

 On Mon, Sep 17, 2012 at 09:10:21PM +0900, Izumi Tsutsui wrote:
 > The man page looks completely out of date and enough to have another PR.

 Well, at least add a line for the new supported hardware, please.
  Thomas

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: wiz@NetBSD.org
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961 (Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter))
Date: Mon, 17 Sep 2012 21:58:29 +0900

 > Well, at least add a line for the new supported hardware, please.

 I don't know the actual product. I hope the submitter will do if it's worth.

 ---
 Izumi Tsutsui

From: Ryo ONODERA <ryo_on@yk.rim.or.jp>
To: gnats-bugs@NetBSD.org, tsutsui@NetBSD.org
Cc: 
Subject: Re: kern/46961 (Please support BCM57762 Ethernet arapter (Apple's
 Thunderbolt Ethernet Adapter))
Date: Tue, 18 Sep 2012 01:56:39 +0900 (JST)

 Hi,

 From: tsutsui@NetBSD.org, Date: Mon, 17 Sep 2012 11:58:29 +0000 (UTC)

 > State-Changed-From-To: open->feedback
 > State-Changed-By: tsutsui@NetBSD.org
 > State-Changed-When: Mon, 17 Sep 2012 20:58:28 +0900
 > State-Changed-Why:
 > Integrated.
 > 
 > Note I've also changed sc->bge_return_ring_cnt initialization in bge_attach()
 > to sync with FreeBSD's bge.

 It works.
 Thank you.

 For the record, after the following acpiecdt0 errors,
 I cannot initialize bge0 of BCM57762 with ifconfig and route add default.
 But this is another PR.
 Please close this PR.

 acpiecdt0: command takes over 10 sec...
 ACPI Exception: AE_ERROR, Returned by Handler for [EmbeddedControl] (20110623/evregion-522)
 ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBPC] (Node 0xfffffe816dffddf0), AE_ERROR (20110623/psparse-560)
 ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node 0xfffffe816dffde20), AE_ERROR (20110623/psparse-560)
 ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBSS] (Node 0xfffffe816e00a1f8), AE_ERROR (20110623/psparse-560)
 ACPI Error: Method parse/execution failed [\_SB_.BAT0._STA] (Node 0xfffffe816e00a138), AE_ERROR (20110623/psparse-560)
 acpibat0: failed to evaluate _STA

 bge0: watchdog timeout -- resetting
 bge0: block failed to stop: reg 0xc00, bit 0x00000002


From: David Laight <david@l8s.co.uk>
To: 
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 18:00:15 +0100

 On Mon, Sep 17, 2012 at 04:38:57PM +0900, Izumi Tsutsui wrote:
 > 
 > >  Allowing 'slightly overlong' packets is useful for certain protocols,
 > >  I'm sure I remember something else, as well as VLAN, extending the
 > >  maximum length.
 > 
 > Then shouldn't it be defined in MI sys/net headers?
 > Why don't we only have ETHERCAP_VLAN_MTU and ETHERCAP_JUMBO_MTU
 > in the capability flag?

 I'm sure 'slightly jumbo' packets came up recently - but I can't
 remember why.
 One possibility is for supporting PPPoE.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: david@l8s.co.uk
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter)
Date: Tue, 18 Sep 2012 02:53:10 +0900

 >  One possibility is for supporting PPPoE.

 I've already checked that sys/net/if_pppoe.c has:
 >> #define PPPOE_MAXMTU	(ETHERMTU - PPPOE_OVERHEAD)
  :
 >> 	sc->sc_sppp.pp_if.if_mtu = PPPOE_MAXMTU;
 so I guess pppoe packets won't be larger than ETHER_MAX_LEN.

 ---
 Izumi Tsutsui

From: David Laight <david@l8s.co.uk>
To: 
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 18:52:22 +0100

 On Tue, Sep 18, 2012 at 02:53:10AM +0900, Izumi Tsutsui wrote:
 > >  One possibility is for supporting PPPoE.
 > 
 > I've already checked that sys/net/if_pppoe.c has:
 > >> #define PPPOE_MAXMTU	(ETHERMTU - PPPOE_OVERHEAD)
 >  :
 > >> 	sc->sc_sppp.pp_if.if_mtu = PPPOE_MAXMTU;
 > so I guess pppoe packets won't be larger than ETHER_MAX_LEN.

 Not usually, but it would be very useful to allow the encasulation
 of full sized ethernet packets.
 Some routers (and ISP side kit) support it.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Robert Swindells <rjs@fdy2.co.uk>
To: tsutsui@ceres.dti.ne.jp
Cc: david@l8s.co.uk, gnats-bugs@NetBSD.org
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 21:52:08 +0100 (BST)

 On Tue, Sep 18, 2012 at 02:53:10AM +0900, Izumi Tsutsui wrote:
  > >  One possibility is for supporting PPPoE.
  > 
  > I've already checked that sys/net/if_pppoe.c has:
  > >> #define PPPOE_MAXMTU	(ETHERMTU - PPPOE_OVERHEAD)
  >  :
  > >> 	sc->sc_sppp.pp_if.if_mtu = PPPOE_MAXMTU;
  > so I guess pppoe packets won't be larger than ETHER_MAX_LEN.

 Our pppoe implementation can use slightly larger packets.

 There is code lower down in sys/net/if_pppoe.c that tests against
 PPPOE_MAXMTU.

 Please don't change this.

 Robert Swindells

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: rjs@fdy2.co.uk
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter)
Date: Tue, 18 Sep 2012 23:19:21 +0900

 > On Tue, Sep 18, 2012 at 02:53:10AM +0900, Izumi Tsutsui wrote:
 >  > >  One possibility is for supporting PPPoE.
 >  > 
 >  > I've already checked that sys/net/if_pppoe.c has:
 >  > >> #define PPPOE_MAXMTU	(ETHERMTU - PPPOE_OVERHEAD)
 >  >  :
 >  > >> 	sc->sc_sppp.pp_if.if_mtu = PPPOE_MAXMTU;
 >  > so I guess pppoe packets won't be larger than ETHER_MAX_LEN.
 > 
 > Our pppoe implementation can use slightly larger packets.
 > 
 > There is code lower down in sys/net/if_pppoe.c that tests against
 > PPPOE_MAXMTU.
 > 
 > Please don't change this.

 I don't understand what you mean.

 ---
 Izumi Tsutsui

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: david@l8s.co.uk
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt
	 Ethernet Adapter)
Date: Tue, 18 Sep 2012 23:24:59 +0900

 >  > >  One possibility is for supporting PPPoE.
 >  > 
 >  > I've already checked that sys/net/if_pppoe.c has:
 >  > >> #define PPPOE_MAXMTU	(ETHERMTU - PPPOE_OVERHEAD)
 >  >  :
 >  > >> 	sc->sc_sppp.pp_if.if_mtu = PPPOE_MAXMTU;
 >  > so I guess pppoe packets won't be larger than ETHER_MAX_LEN.
 >  
 >  Not usually, but it would be very useful to allow the encasulation
 >  of full sized ethernet packets.
 >  Some routers (and ISP side kit) support it.

 If such optional encapsulation that requires hardware and
 driver support isn't defined in MI sys/net/if_ether.h,
 it means "we don't support it" and no worth to tweak
 individual drivers for it (and it isn't relevant to this PR).

 Please open a new PR if you really want to support new features.
 ---
 Izumi Tsutsui

State-Changed-From-To: feedback->closed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Fri, 28 Sep 2012 21:42:47 +0900
State-Changed-Why:
BCM57762 support has been committed and confirmed working.
Adding only one device to updated-only-once-in-last-nine-year man page
just confuses users, IMO.


From: "Jeff Rizzo" <riz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: [netbsd-6] src/sys/dev/pci
Date: Wed, 24 Oct 2012 03:35:42 +0000

 Module Name:	src
 Committed By:	riz
 Date:		Wed Oct 24 03:35:42 UTC 2012

 Modified Files:
 	src/sys/dev/pci [netbsd-6]: pcidevs

 Log Message:
 Apply patch (requested by msaitoh in ticket #631):

  This patch doesn't include any changes that rename ID.

 ==================================================================
 sys/dev/pci/pcidevs	1.1103,1.1105,1.1109-1.1112,1.1114,1.1119-1.1124,
 			1.1126-1.1128,1.1130-1.1136,1.1138-1.1142

 	Added Ricoh 5CE823.
 	Added some AMD/ATI devices.
 	Add Marvell Yukon 88e8040 ethernet.
 	More broadcom stuff.
 	Add IDs for Fresco Logic and their FL1000 and FL1009 xHCI chips.
 	NEC uPD720100A is USB2.
 	Add NEC uPD720200, a USB3 Host Controller.
 	Add Intel Sandybridge integrated graphics.
 	Add Marvell SoC 88F6282.
 	Add XGI Technology's devices.
 	Add some Intel's devices.
 	Add more FREESCALE devices.
 	Fix RICOH RU5230 description.
 	Add some Intel 7 series devices.
 	Add some ATI and SIS devices. Fixes PR#39580.
 	Add VirtualBox ids.
 	Add EG20T PCH.  Closes PR/45567.
 	Add LSI MegaRAID SAS2208.
 	Add 82GM45_KT for puc(4).
 	Add some Intel's KT (Serial over LAN) devices.
 	Add some PCI AHCI controllers, from linux.
 	Added ALTERA EP4CGX15BF14C8N entry.
 	Add Broadcom BCM57762 Gigabit Ethernet, per PR kern/46961.
 	Add ASMEDIA ASM1061.
 	Add Lava Computers SSERIAL-PCI single serial port adapter.
 	Add Intel Ivy Bridge host bridge and integrated graphics device IDs.
 	Add Intel Centrino Wireless-N 2230.
 	Pull in changes from matt-nb5-mips64 (RMI & NETLOGIC).
 	Add SB600_USB_OHCI0 again. This was (accidentally) removed in
 	rev. 1.1105.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1102.2.7 -r1.1102.2.8 src/sys/dev/pci/pcidevs

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Jeff Rizzo" <riz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: [netbsd-6] src/sys/dev/mii
Date: Wed, 24 Oct 2012 03:41:51 +0000

 Module Name:	src
 Committed By:	riz
 Date:		Wed Oct 24 03:41:51 UTC 2012

 Modified Files:
 	src/sys/dev/mii [netbsd-6]: miidevs

 Log Message:
 Pull up following revision(s) (requested by msaitoh in ticket #633):
 	sys/dev/mii/miidevs: revision 1.106
 	sys/dev/mii/miidevs: revision 1.107
 	sys/dev/mii/miidevs: revision 1.108
 	sys/dev/mii/miidevs: revision 1.109
 Sync a comment with a fact.
 There is MII_OUI() in miivar.h not mii.h after 2001.
 Add VSC8221
 Add AR8035
 Add another Broadcom OUI and BCM57765 1000BASE-T media interface.
 Per PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.105 -r1.105.4.1 src/sys/dev/mii/miidevs

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46961 CVS commit: [netbsd-6] src/sys/dev
Date: Mon, 26 Aug 2013 04:00:16 +0000

 Module Name:	src
 Committed By:	msaitoh
 Date:		Mon Aug 26 04:00:16 UTC 2013

 Modified Files:
 	src/sys/dev/mii [netbsd-6]: brgphy.c
 	src/sys/dev/pci [netbsd-6]: if_bge.c if_bgereg.h

 Log Message:
 Pull up following revision(s) (requested by tsutsui in ticket #652):
 	sys/dev/mii/brgphy.c                            1.60
 	sys/dev/pci/if_bge.c                            1.202
 	sys/dev/pci/if_bgereg.h                         1.57
 Add support for BCM57762 and BCM57765, found in Apple's Thunderbolt
 to Gigabit Ethernet adapter.  PR kern/46961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.59 -r1.59.8.1 src/sys/dev/mii/brgphy.c
 cvs rdiff -u -r1.200 -r1.200.2.1 src/sys/dev/pci/if_bge.c
 cvs rdiff -u -r1.56 -r1.56.18.1 src/sys/dev/pci/if_bgereg.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.