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:
(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.
Home