Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

MFC r263957:
Increase the number of TX DMA segments from 32 to 35. It turned
out 32 is not enough to support a full sized TSO packet.
While I'm here fix a long standing bug introduced in r169632 in
bce(4) where it didn't include L2 header length of TSO packet in
the maximum DMA segment size calculation.

MFC r258830:
Add support for BCM57764, BCM57767, BCM57782, BCM57786 and BCM57787.
PR: 184304

MFC r253483:
Add support for upcoming BCM5725 (ASIC 5762) controller. This is a
new 1Gb server controller chip that will be going into production
soon.
BCM5725 combines MAC with triple-speed PHY, a Network Controller
Sideband Interface (NC-SI) and on-chip memory buffer in a single
device. BCM5725 has an Application Processing Engine (APE) that is
capable of on-chip management and offloading features. BCM5725
supports high-precision clock, time stamp registers for
receive/transmit packets and programmable trigger inputs and
watchdog timeouts. These new features are not yet supported by
bge(4).
Many thanks to Broadcom for continuing to support FreeBSD!

MFC r253480:
Setup the PCIE Fast Training Sequence (FTS) value to prevent
transmit hangs for 57766 and non Ax versions of 57765.
While here, correct definition of BGE_CHIPREV_57765_AX.

MFC r253408:
Implement workaround for BCM5719/BCM5720 TX hang.
The read DMA request logic operation is based on having sufficient
available space in the transmit data buffer (TXMBUF) before a read
DMA can be requested. There are four read DMA channels that use
the TXMBUF, and the logic checks if the available free space in the
TXMBUF is large enough for all the data in the four Send Buffers
for which buffer descriptors have been fetched. The Enable_Request
signal is asserted only if the free TXMBUF space is larger than the
sum of the four DMA length registers. The power-up default value
of BGE_RDMA_LSO_CRPTEN_CTRL register bit 25 (bit 21 on BCM5720) is
zero, which selects the DMA length registers to connect to the
input of the adder block. The DMA length registers are
asynchronously reset following BCM5719/BCM5720 power-up, and due to
the lack of synchronous deassertion of the length registers reset
signal these resisters may contain uninitialized values following
the reset deassertion.
In the case of the failure the uninitialized DMA length register
values added up to more than the TXMBUF size, which prevented the
assertion of the Enable_Request signal and any subsequent read DMA
to start. This lockup condition is the root cause of failing to
generate any transmit traffic.

To workaround the issue, select alternate output of multiplexers
and transmit the first four Ethernet frames. This overwrites the
DMA length registers with valid values.

MFC r252404:
Fix triggering false watchdog timeout as done in bce(4) when
controller is in PAUSE state.

MFC r251482,251733:
r251482:
Correct setting TX random backoff register. This register is
implemented as a 10 bits linear feedback shift register so only
lower 10 bits are valid.
Because this register is used to initialize random backoff interval
register only when resolved duplex is half-duplex, it wouldn't have
caused issues in these days.

r251733:
Fix a typo introduced in r213280. IFM_OPTIONS macro should see
current media word.

MFC r243686:
Add preliminary support for BCM57766 ASIC.
While I'm here add BCM57762 device id which is found on Apple
Thunderbolt ethernet.

MFC r241983-241985:
r241983:
Do not hardcode phy address. Multi-port controllers use different phy
address.

r241984:
Ethernet@WireSpeed is defined for 1000baseT adapter to establish a
link at a lower speed so enabling it for fiber adapters is wrong.
Fix the issue by setting BGE_PHY_NO_WIRESPEED such that brgphy(4)
wouldn't enable the feature.
While I'm here move PHY specific feature/bug configuration to new
location(just before mii attach) for readability.

r241985:
For fast ethernet controllers, Ethernet@WireSpeed is not defined so
explicitly set BGE_PHY_NO_WIRESPEED flag.

MFC r241438:
Add APE firmware support and improve firmware handshake procedure.
This change will enable IPMI access on 5717/5718/5719/5720 and 5761
controllers. Because ASF is not available when APE firmware is
present, bge_allow_asf tunable is ignored when driver detects APE
firmware. Also bge(4) no longer performs two resets(one blind
reset and the other reset with firmware in mind) in device attach.
Now bge(4) performs a reset with enough information in bge_reset().
The APE firmware also needs special handling to make suspend/resume
work but it was not implemented yet.

With this change, bge(4) should work on any 5717/5718/5719/5720
controllers. Special thanks to Mike Hibler at Emulab who setup
remote debugging on Dell R820. Without his help I couldn't be able
to address several issues happened on Dell Rx20 systems. And many
thanks to Broadcom for continuing to support FreeBSD!

Submitted by: davidch (initial version)
H/W donated by: Broadcom
Tested by: many
Tested on: Del R820/R720/R620/R420/R320 and HP Proliant DL 360 G8

MFC r241436:
Rework controller reset procedure. Previously driver saved
BGE_PCI_PCISTATE register before issuing global reset. After
issuing reset, it reads BGE_PCI_PCISTATE register again and
compares the saved register value and current value. It was used to
know whether the global reset operation was completed or not.
Unfortunately, this logic caused several issues on recent BCM5717/
5718/5719 and BCM5720 controllers. It seems APE firmware accesses
some registers while global reset is in progress such that reading
BGE_PCI_PCISTATE register after reset does not yield old pre-reset
state value. This resulted in consuming too much time in global
reset and sometimes it couldn't successfully complete reset.

The BGE_MISCCFG_RESET_CORE_CLOCKS of BGE_MISC_CFG register is
self-clearing bit so driver is able to know the reset completion.
But the core-lock reset will disable indirect/flat/standard access
modes such that driver cannot poll BGE_MISCCFG_RESET_CORE_CLOCKS
bit of BGE_MISC_CFG register. So just wait enough time for
core-clock reset to complete.
Data sheet says driver should wait 100us for PCI/PCI-X devices and
100ms for PCIe devices. I chose 1ms for PCI/PCI-X since this value
was used for many years in bge(4). For PCIe devices, use 100ms as
recommended by data sheet.

bge_chipinit() also cleared BGE_MAC_MODE register which shall clear
firmware configured mode information. I think this will result in
losing ASF/IPMI link in device attachment. Let bge_reset() honor
firmware configured BGE_MAC_MODE register and don't announce driver
is UP in bge_reset(). Firmware should have control over driver until
it's fully initialized by driver.

While I'm here, enable workaround for PCI-X BCM5704 A0 in
bge_reset(). This will prevent internal arbitration logic from
switching to the other DMA engine after a retry cycle.

MFC r241388-241393:
r241388:
If the maximum payload size is 256 bytes or more, set the DMA write
water mark to 256 bytes. Otherwise controller will encounter DMA
write under run errors and would result in RX DMA hang. If the
maximum payload size is 128 bytes, the water mark is set to 128
bytes as usual.
While here, set maximum read request size to 2048 for BCM5719/BCM5720.
For other PCIe devices, use 4096. And reprogram the maximum read
request size whenever device reset is performed.

r241389:
On PHY write error use hex number to show the value.
Add more comments.

r241390:
Honor PHY type fiber for BCM5717/BCM5718/BCM5719/BCM5720.

r241391:
Do not force PCIe 1.0a mode in device reset on BCM5717 and newer
controllers. BCM5785 does not require PCI 1.0a mode as well during
reset.

r241392:
Fix a long standing VCPU reset sequence bug on BCM5906.
The VCPU(Virtual CPU) of BCM5906 is used to provide a mechanism to
control the bootcode execution and to pick up configuration data
stored inside the EEPROM.
The bootcode of BCM5906 will check the BGE_VCPU_STATUS_DRV_RESET
bit to decide which booting procedure to choose.
Data sheet indicates the VCPU of BCM5906 should set
BGE_VCPU_STATUS_DRV_RESET bit *before* VCPU reset or global reset.

r241393:
Remove unnecessary delay. I don't see any comments in data sheet
that requires 10ms delay after device reset. Because that code was
there from day 1, I guess it was added to give enough settlement
time after updating BGE_MAC_MODE register.
The recommended delay time for BGE_MAC_MODE after updating is 40us
and it was already done in r241219.

MFC r232849-232850:
r232849:
Show PCI bus speed and width as well as running mode of PCI-X
device in device attach. This would help to narrow down issue to a
specific controller and operating mode of the controller.
While I'm here rename BGE_MISCCFG_BOARD_ID with
BGE_MISCCFG_BOARD_ID_MASK.

r232850:
Make if_ierrors updated whenever any of the following counters are
updated.
o Number of times NIC ran out of RX buffer descriptors
o Number of inbound packet errors
o Number of inbound packets that were chosen to be discarded
Previously only the discarded packet counter was used to update
if_ierrors. This change fixes wrong if_ierrors counter on
BCM570[0-4] controllers. For BCM5705 and later controllers bge(4)
already correctly counted it.

Reported by: Eugene Grosbein <egrosbein <> rdtc dot ru>

MFC r232848:
Add workaround for PCI-X BCM5704 controller that live behind
AMD-8131 PCI-X bridge. The bridge seems to reorder write access to
mailbox registers such that it caused watchdog timeouts by
out-of-order TX completions.

Tested by: Michael L. Squires <mikes <> siralan dot org >

MFC r230286,230337-230338,231159:
r230286:
Introduce a tunable that disables use of MSI.
Non-zero value will use INTx.

r230337-230338:
Rename dev.bge.%d.msi_disable to dev.bge.%d.msi which matches
enable/disable and default it to on.

r231159:
Call bge_add_sysctls() early and especially before bge_can_use_msi() so
r230337 actually has a chance of working and doesn't always unconditionally
disable the use of MSIs.

MFC r228479-228480:
r228479:
BCM5720 performance tweak from Broadcom.
o Allow multiple outstanding read requests from non-LSO read DMA engine.
o Allow 4KB burst length reads for non-LSO frames.
o Enable 512B burst length reads for buffer descriptors.

r228480:
Destroy DMA tag for jumbo RX buffer in device detach.

MFC r226871-226872:
r226871:
Add initial BCM5720 support.
Many thanks to Broadcom for continuing support of FreeBSD.

Submitted by: Geans Pin at Broadcom (initial version)
H/W donated by: Broadcom

r226872:
Disable updating InputDiscards counter for BCM5717, BCM5718,
BCM5719 A0 and BCM5720 A0 and add comment why driver does not try
to read it.

MFC r226814-226815,226820-226821,226864,226866-226867:
r226814:
Rename definition of BGE_SOFTWARE_GENCOMM_* to more readable ones.
The origin of GENCOMM seems to come from Alteon Tigon Host/NIC
interface definition where it defines general communications region
which is active when firmware is loaded and running. This region
was used in communication between the host and processor internal
to the Tigon chip.
Broadcom data sheet also defines the region as 'Software Gencomm'
in NetXtreme memory map but lacks detailed description of its
interface so it was hard to know which ones are used for which
interface.
This change shall slightly enhance readability.

No functional changes.

r226815:
Define MAC address mail box and use it instead of using
hard-coded value.

r226820:
Offset 0x6810 is RX-RISC event register. Rename BGE_CPU_EVENT with
BGE_RX_CPU_EVENT for readability.
Additionally define BGE_TX_CPU_EVENT for TX-RSIC event register(BCM570[0-4] only).

r226821:
SRAM offset 0x0C04 is used by driver to inform the IPMI/ASF firmware
about the various driver events like load, unload, reset, suspend,
restart, and ioctl operations.
Define driver's event rather than using hard-coded values. We don't
still send suspend/resume event to firmware.

Previously bge(4) used BGE_SDI_STATUS to send events. Because driver
has to access firmware mail box to inform current state, using
BGE_SDI_STATUS register was wrong. The end result was the same as
BGE_SDI_STATUS is 0x0C04.

No functional changes.

r226864:
Rename BGE_FW_DRV_ALIVE/BGE_FW_PAUSE to BGE_FW_CMD_DRV_ALIVE/BGE_FW_CMD_PAUSE.
Also add more firmware commands(not used yet).
No functional changes.

r226866:
Rename hard-coded value 1 << 14 with BGE_RX_CPU_DRV_EVENT.
This bit(SW event 7 in publicly available data sheet) is used to
make RX CPU handle a firmware command and the bit is automatically
cleared after RX CPU completed the command.
Generally firmware command takes the following steps.
1. Write BGE_SRAM_FW_CMD_MB with a command.
2. Write BGE_SRAM_FW_CMD_LEN_MB with the length of the command in bytes.
3. Write BGE_SRAM_FW_CMD_DATA_MB with actual command data.
4. Generate BGE_RX_CPU_EVENT and let firmware handle the command.
5. Wait for the ACK of the firmware command.

No functional changes.

r226867:
Define BGE_FW_HB_TIMEOUT_SEC and remove one more magic value.
bge(4) sends BGE_FW_CMD_DRV_ALIVE command to firmware every 2
seconds. BGE_FW_CMD_DRV_ALIVE command requires 4 bytes data. This
data contains timeout value in seconds until the next
BGE_FW_CMD_DRV_ALIVE command.
Broadcom recommends driver set the value 3 times longer than the
interval that it sends BGE_FW_CMD_DRV_ALIVE. Currently bge(4) uses
3 seconds so probably we have to increase it in future and use
different ALIVE command(e.g. BGE_FW_CMD_DRV_ALIVE3).

No functional changes.

MFC r226749,226770,226804-226807:
r226749:
Whitespace nits.

r226770:
Fix long standing bge_sysctl_debug_info() issues.
o Protect bge(4) status block access and register dump with driver lock.
o Add missing bus_dmamap_sync() before dumping status block.
o Use minimum status block size, 32 bytes, for status block dump on most
controllers except BCM5700 AX/BX.
While I'm here, make the handler show 5717 Plus in hardware flags.

r226804:
Make CPMU handle GPHY power down control on controllers that have
CPMU capability.

r226805:
It is known that all Broadcom controllers have 4GB boundary DMA
bug. Apply workaround to all controllers.

r226806:
Broadcom says BCM5755 or higher and BCM5906 have short DMA bug.
Apply workaround to these controllers.

r226807:
BCM5719 cannot handle DMA requests for DMA segments that have
larger than 4KB in size. However the maximum DMA segment size
created in DMA tag is 4KB, so we wouldn't encounter the issue here.
Just record this issue such that let developers not to create a DMA
segment that is larger than 4KB for BCM5719. It's possible to split
a DMA segment into multiple smaller ones in run time but I believe
it's not worth to implement that.

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)

Add initial BCM5719 support. TSO and jumbo frame was intentionally
disabled for BCM5719 A0 revision due to known hardware errata.
Many thanks to Broadcom for continuing support of FreeBSD.

Submitted by: Geans Pin at Broadcom

Enable Ethernet@WireSpeed for BCM5718/BCM57765 family. While I'm
here inverse meaning of PHY flag as Ethernet@WireSpeed is enabled
for most PHYs.

Add initial BCM57765 family support. The BCM57765 family seems to
have similar hardware features of BCM5718 family except the number
of receive return ring is 4. The BCM57765 family is known to
support IEEE 802.3az EEE(Energy Efficient Ethernet) but this change
does not include EEE support code. I hope EEE is implemented in
near future.
This change will support BCM57761, BCM57765, BCM57781, BCM57785,
BCM57791 and BCM57795. All hardware offloading features are
supported and suspend/resume also should work.
Many thanks to Broadcom for continuing support of FreeBSD.

Tested by: Paul Thornton (prt <> prt dot org)
HW donated by: Broadcom

Add initial jumbo frame support for BCM5714/BCM5715 and BCM5780.
Unlike other controllers which have more advanced jumbo support,
these controllers have one send ring, one standard receive producer
ring and one receive return ring. In order to receive jumbo frames
on the controllers, driver now will increase Rx buffer size to 9k.
Two Rx modes are supported on these controllers and I chose
standard Rx BDs over extended Rx BDs. The extended Rx BD mode
allows up to 4 segmentations for each Rx BDs such that kernel does
not have to allocate large buffer of contiguous memory for
receiving. The extended Rx BD mode is already used on controllers
that have separate jumbo receive ring. However, using extended Rx
BDs on BCM5714/BCM5715/BCM5780 reduces the number of Rx BDs to 256
entries which in turn may reduce the performance. Also UMA backed
page allocator for jumbo frame returns contiguous memory so using
extended Rx BD has no advantage on FreeBSD unless highly customized
local allocator implemented in driver is used.
To use jumbo buffers in standard receive ring, Rx buffer allocation
handler was changed to allocate MJUM9BYTES sized mbuf.

PR: kern/155192
Tested by: Vijay Singh <vijju.singh <> gmail dot com>
Submitted by: mjacob (initial version)

Add initial BCM5718 family support. The BCM5718 family includes
the dual port BCM5717 and BCM5718 devices which are intended for
mainstream workstation and entry-level server designs and
represents the twelfth generation of NetXtreme Ethernet controllers.
This family is the successor to the BCM5714/BCM5715 family and
supports IPv4/IPv6 checksum offloading, TSO, VLAN hardware tagging,
jumbo frames, MSI/MSIX, IOV, RSS and TSS.

This change set supports all hardware features except IOV and
RSS/TSS. Unlike its predecessors, only extended RX buffer
descriptors can be posted to the jumbo producer ring. Single RX
buffer descriptors for jumbo frame are not supported. RSS requires
a more substantial set of changes and will apply to a larger set
of NetXtreme devices so RSS/TSS multi-queue support will be
implemented in a future releases.

Special thanks to Broadcom who kindly sent a sample board to me
and to davidch who gave provided the initial support code.

Submitted by: davidch (initial version)
HW donated by: Broadcom

Apply the same workaround for SDI flow control used on BCM5906 A1
to BCM6906 A0/A2. This should fix a long standing BCM5906 A2 lockup
issues. Data sheet explicitly mentions BCM5906 A0, A1 and A2 use
de-pipelined mode on these revisions.
Special thanks to Buganini who tried all combinations of
experimental patches for more than 10 days.

Tested by: Buganini <buganini <> gmail dot com >

Add workaround for BCM5906 A1 controller silicon bug. When
auto-negotiation results in half-duplex operation, excess collision
on the ethernet link may cause internal chip delays that may result
in subsequent valid frames being dropped due to insufficient
receive buffer resources. The workaround is to choose de-pipeline
method as a flow control decision for SDI. De-pipeline method
allows only 1 data in TxMbuf at a time such that a request to RDMA
from SDI is made only when TxMbuf is empty. Thanks for david for
providing detailed errata information.

Enable TX MAC state machine lockup fix for both BCM5755 or higher
and BCM5906. Publicly available data sheet just says it may happen
due to corrupted TxMbuf.

Add workaround for BCM5906 controller silicon bug. If device
receive two back-to-back send BDs with less than or equal to 8
total bytes then the device may hang. The two back-to-back send
BDs must be in the same frame for this failure to occur.
Thanks to davidch for detailed errata information.

Reviewed by: davidch

Convert the PHY drivers to honor the mii_flags passed down and convert
the NIC drivers as well as the PHY drivers to take advantage of the
mii_attach() introduced in r213878 to get rid of certain hacks. For
the most part these were:
- Artificially limiting miibus_{read,write}reg methods to certain PHY
addresses; we now let mii_attach() only probe the PHY at the desired
address(es) instead.
- PHY drivers setting MIIF_* flags based on the NIC driver they hang
off from, partly even based on grabbing and using the softc of the
parent; we now pass these flags down from the NIC to the PHY drivers
via mii_attach(). This got us rid of all such hacks except those of
brgphy() in combination with bce(4) and bge(4), which is way beyond
what can be expressed with simple flags.

While at it, I took the opportunity to change the NIC drivers to pass
up the error returned by mii_attach() (previously by mii_phy_probe())
and unify the error message used in this case where and as appropriate
as mii_attach() actually can fail for a number of reasons, not just
because of no PHY(s) being present at the expected address(es).

Reviewed by: jhb, yongari

Remove bge_tx_buf_ratio, unused member of softc.

Overhaul MII register access routine and remove unnecessary
BGE_MI_MODE register accesses. Previously bge(4) used to read
BGE_MI_MODE register to detect whether it needs to disable
autopolling feature or not. Because we don't touch autopolling in
other part of driver there is no reason to read BGE_MI_MODE
register given that we know default value in advance. In order to
achieve the goal, check whether the controller has CPMU(Central
Power Mangement Unit) capability. If controller has CPMU feature,
use 500KHz MII management interface(mdio/mdc) frequency regardless
core clock frequency. Otherwise use default MII clock. While I'm
here, add CPMU register definition.

In bge_miibus_readreg(), rearrange code a bit and remove goto
statement. In bge_miibus_writereg(), make sure to restore
autopolling even if MII write failed. The delay time inserted after
accessing BGE_MI_MODE register increased from 40us to 80us.

The default PHY address is now stored in softc. All PHYs supported
by bge(4) currently uses PHY address 1 but it will be changed when
we add newer controllers. This change will make it easier to change
default PHY address depending on PHY models.

Submitted by: davidch

Separate common flags into controller specific and PHY related
flags. There should be no functional changes. This change will make
it easy to add more quirk/flags in future.

Reviewed by: davidch

Enable fix for read DMA FIFO overruns on controllers that have this
fix. Note, we still need workaround for controllers that lacks this
fix and it needs more work in RX BD updating.

Submitted by: davidch

Allow write DMA to request larger DMA burst size to get better
performance on BCM5785.

Obtained from: OpenBSD

Implement hardware MAC statistics for BCM5705 or newer Broadcom
controllers. bge(4) exported MAC statistics on controllers that
maintain the statistics in the NIC's internal memory. Newer
controllers require register access to fetch these values. These
counters provide useful information to diagnose driver issues.

Set the number of RX frames to receive after RX MBUF low watermark
has reached. This reduced number of dropped frames when
flow-control is enabled. Previously it dropped incoming frames once
RX MBUF low watermark has reached. The value used in MAC RX MBUF
low watermark is greater than or equal to 4 so receiving two more
RX frames should not be a problem.

Obtained from: OpenBSD

Handle PAE case correctly. You cannot effectively specify a 4GB
boundary in PAE case so use a 2GB boundary for PAE as suggested by
jhb.

Pointed out by: jhb
Reviewed by: jhb

Split common parent DMA tag into ring DMA tag and TX/RX mbuf DMA
tag. All controllers that are not BCM5755 or higher have 4GB
boundary DMA bug. Previously bge(4) used 32bit DMA address to
workaround the bug(r199670). However this caused the use of bounce
buffers such that it resulted in poor performance for systems which
have more than 4GB memory. Because bus_dma(9) honors boundary
restriction requirement of DMA tag for dynamic buffers, having a
separate TX/RX mbuf DMA tag will greatly reduce the possibility of
using bounce buffers. For DMA buffers allocated with
bus_dmamem_alloc(9), now bge(4) explicitly checks whether the
requested memory region crossed the boundary or not.
With this change, only the DMA buffer that crossed the boundary
will use 32bit DMA address. Other DMA buffers are not affected as
separate DMA tag is created for each DMA buffer.
Even if 32bit DMA address space is used for a buffer, the chance to
use bounce buffer is still very low as the size of buffer is small.
This change should eliminate most usage of bounce buffers on
systems that have more than 4GB memory.

More correct fix would be teaching bus_dma(9) to honor boundary
restriction for buffers created with bus_dmamem_alloc(9) but it
seems that is not easy.

While I'm here cleanup bge_dma_map_addr() and remove unnecessary
member variables in bge_dmamap_arg structure.

Tested by: marcel

It seems all Broadcom controllers have a bug that can generate UDP
datagrams with checksum value 0 when TX UDP checksum offloading is
enabled. Generating UDP checksum value 0 is RFC 768 violation.
Even though the probability of generating such UDP datagrams is
low, I don't want to see FreeBSD boxes to inject such datagrams
into network so disable UDP checksum offloading by default. Users
still override this behavior by setting a sysctl variable or loader
tunable, dev.bge.%d.forced_udpcsum.

I have no idea why this issue was not reported so far given that
bge(4) is one of the most commonly used controller on high-end
server class systems. Thanks to andre@ who passed the PR to me.

PR: kern/104826

Use Miscellaneous Configuration Register bit definition instead of
magic number.

Remove unused macros.

Reviewed by: bde

Fix a bug introduced in r199011. When bge(4) reuses loaded RX
buffers it should also reinitialize RX descriptors otherwise some
stale data could be passed to controller. This could end up with
mbuf double free or unexpected NULL pointer dereference in upper
stack. To fix the issue, save loaded buffer's length and
reinitialize RX descriptors with the saved value whenever bge(4)
reuses the loaded RX buffers.
While I'm here, increase the number of RX buffers to 512 from 256.
This simplifies RX buffer handling as well as giving more RX
buffers. Controller supports just fixed number of RX buffers
(i.e. 512) and bge(4) used to rely on hope that our CPU is fast
enough to keep up with the controller. With this change, bge(4)
will use 1MB for RX buffers but I don't think it would cause
problems in these days.

Reported by: marcel
Tested by: marcel

For controllers that has dual mode PHY(copper or fiber) interfaces
over GMII, make sure to enable GMII. With this change brgphy(4) is
used to handle the dual mode PHY. Since we still don't have a sane
way to pass PHY specific information to mii(4) layer special
handling is needed in brgphy(4) to determine which mode of PHY was
configured in parent interface.
This change make BCM5715S work.

Tested by: olli
Obtained from: OpenBSD
MFC after: 1 week

o Add PCI ID for BCM 5756.
o Don't enable BGE_FLAG_BER_BUG on both 5722 and 5756, and based
on their PCI IDs rather than their chip IDs.

Reported by: several PC-BSD users via kmoore
Reviewed by: yongari, imp, jhb, davidch
Sponsored by: iXsystems, Inc.
MFC after: 2 weeks

Create sysctl node(dev.bge.%d.focred_collapse) instead of
hw.bge.forced_collapse. hw.bge.forced_collapse affects all bge(4)
controllers on system which may not desirable behavior of the
sysctl node. Also allow the sysctl node could be modified at any
time.

Reviewed by: bde (initial version)

Implement TSO for BCM5755 or newer controllers. Some controllers
seem to require a special firmware to use TSO. But the firmware is
not available to FreeBSD and Linux claims that the TSO performed by
the firmware is slower than hardware based TSO. Moreover the
firmware based TSO has one known bug which can't handle TSO if
ethernet header + IP/TCP header is greater than 80 bytes. The
workaround for the TSO bug exist but it seems it's too expensive
than not using TSO at all. Some hardwares also have the TSO bug so
limit the TSO to the controllers that are not affected TSO issues
(e.g. 5755 or higher).
While I'm here set VLAN tag bit to all descriptors that belengs to
a frame instead of the first descriptor of a frame. The datasheet
is not clear how to handle VLAN tag bit but it worked either way in
my testing. This makes it simplify TSO configuration a little bit.

Big thanks to davidch@ who sent me detailed TSO information.
Without this I was not able to implement it.

Tested by: current

Fix two long standing bugs on bge(4). Most pre BCM5755 controllers
have a DMA bug when buffer address crosses a multiple of the 4GB
boundary(e.g. 4GB, 8GB, 12GB etc). Limit DMA address to be within
4GB address for these controllers. The second DMA bug limits DMA
address to be within 40bit address space. This bug applies to
BCM5714 and BCM5715 and 5708(bce(4) controller). This is not
actually a MAC controller bug but an issue with the embedded PCIe
to PCI-X bridge in the device. So for BCM5714/BCM5715 controllers
also limit the DMA address to be within 40bit address space.
Special thanks to davidch@ who gave me detailed errata information.
I think this change will fix long standing bge(4) instability
issues on systems with more than 4GB memory.

Reviewed by: davidch

For MSI case, interrupt is not shared and we don't need to force
PCI flush to get correct status block update. Add an optimized
interrupt handler that is activated for MSI case. Actual interrupt
handling is done by taskqueue such that the handler does not
require driver lock for Rx path. The MSI capable bge(4) controllers
automatically disables further interrupt once it enters interrupt
state so we don't need PIO access to disable interrupt in interrupt
handler.

Use capability pointer to access PCIe registers rather than
directly access them at fixed address. While I'm here don't touch
other bits of PCIe device control register except max payload size.

Reviewed by: marius

Remove extra white space.

Reimplement Rx buffer allocation to handle dma map load failure.
Introduce two spare dma maps for standard buffer and jumbo buffer
respectively. If loading a dma map failed reuse previously loaded
dma map. This should fix unloaded dma map is used in case of dma
map load failure. Also don't blindly unload dma map and defer
dma map sync and unloading operation until we know dma map for new
buffer is successfully loaded. This change saves unnecessary dma
load/unload operation. Previously bge(4) tried to reuse mbuf
with unloaded dma map which is really bad thing in bus_dma(9)
perspective.
While I'm here update if_iqdrops if we can't allocate Rx buffers.

bge(4) already switched to use UMA backed page allocator and local
memory allocator for jumbo frame was removed long time ago. Remove
no more used macros.

Correct MSI mode register bits.

Remove common DMA tag used for TX/RX mbufs and create Tx DMA tag
and Rx DMA tag separately. Previously it used a common mbuf DMA tag
for both Tx and Rx path but Rx buffer(standard ring case) should
have a single DMA segment and maximum buffer size of the segment
should be less than or equal to MCLBYTES. This change also make it
possible to add TSO with minor changes.

- Give a name to the host coalescing bug fix WDMA mode register bit instead
of using hardcoded value in the code.
Obtained from: OpenBSD

- Add support for new BGE chips (5761, 5784 and 57780). These chips uses new
BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revision.
- Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS).
- Add IDs for Fujitsu-branded Broadcom adapters.

PR: kern/127587
Tested by: Thomas Quinot <thomas@quinot.org> (BCM7561 A0)
MFC after: 2 weeks
Obtained from: OpenBSD

- Ensure that INTx isn't disabled, as these chips apparently have a
quirk requiring it to be enabled even when using MSI. This makes
the latter work again after r189285.
- Remove a comment which no longer applies since r190194.

- In bge_ifmedia_upd_locked() take advantrage of LIST_FOREACH().
- If boot verbose, print asicrev, chiprev and bus type on attach.
- For PCI Express devices:
1) Adjust max read request size to 4Kbytes
2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit()
Though 1) does not seem to have much to do with the poor TX performance
observed on PCI Express bge(4), 2) does fix the problem. [1]
- Nuke the RX CPU self-diag, which prevents working cards from working
(Linux tg3 does not have this diag neither does OpenBSD's bge(4)).
The increasing of the firmware handshaking timeout to 20000 retries
done as part of the original commit isn't merged as way already have a
way higher BGE_TIMEOUT of 100000.

PR: 119361 [1]
Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD

Use bus_{read,write}_4(9) instead of bus_space_{read,write}_4(9)
in order to get rid of the bus space handle and tag in the softc.

MFC after: 1 month

Improve the integration of BCM5906[M] support:
- Rename BGE_FLAG_EEPROM to BGE_FLAG_EADDR to underline it's absence means
"there's no chip containing an Ethernet address fitted to the BGE chip
so we have to get it from the firmware instead" rather than "there's no
EEPROM, but maybe NVRAM or something else".
- Don't treat BCM5906[M] generally like chips w/o BGE_FLAG_EADDR set, just
in the two cases really necessary. This gets us line with the original
patch for DragonFlyBSD.
- For sparc64 restore the intended behavior of obtaining the Ethernet
address from the firmware in case BGE_FLAG_EADDR is not set, even for
BCM5906[M].
- Fix some style(9) bugs introduced with rev. 1.208 of if_bge.c

Approved by: jhb
Additional testing by: Thomas Nystroem (BCM5906)

Use a better approach to force the interrupt which should work for
all cards/modes.
In addition to the intr forcing added with rev. 1.205 adopt the other
places to use the same logic.

We need to exclude a few chips/revisions (5700, 5788) from using the
enhanced version and fall back to the old way as that is the only
method they support.

Tested by: phk
Suggested by: davidch, Broadcom (thanks a lot for the help!)
MFC after: 16 days

Add support for the BCM5906[M] adapters. These adapters only support
10/100 operation and place the mailbox registers at a different offset.
They also do not have an EEPROM, so the MAC address must be read from
NVRAM instead.

MFC after: 1 month
PR: kern/118975
Submitted by: benjsc, Thomas Nyström thn at saeab dot se
Submitted by: sephe (original patch for DragonflyBSD)

Style tweak to the 5722 chipid to match the rest of this file.

Flesh out support for the BCM5722 by recognizing the phy on the 5722 and
the specific ASIC revision.

MFC after: 1 week
Obtained from: OpenBSD (mii/phy bits)

Add a flag for Ethernet@WireSpeed capability and correct chip revisions.
The idea was taken from OpenBSD and cross-referenced with Linux driver.

Add support for the BMC5722.

Reported by: Chris Shenton <chris at shenton dot org> on current@
Approved by: imp (mentor)

Rearrange DMA read/write control register settings based on document snippet
provided by davidch via glebius.

PR: kern/96806

- Add support/quirks for the on-board BGEs found in Sun Blade 1500
Blade 2500, Fire V210 and probably some other sparc64 machines.
These chips are typically not fitted with an EEPROM which means
that we have to obtain the MAC address via OFW and that some chip
tests will just always fail.
These changes are based on the respective code found in OpenBSD
with some additional info obtained from OpenSolaris and some style
suggestions by jkim@. They also have the desired side-effect of
respecting the 'local-mac-address?' system configuration variable
for the affected BGEs.
- In bge_attach() factor out calling bge_release_resources() before
going to the fail label into the fail label as well as replace a
magic 6 with ETHER_ADDR_LEN.

Reviewed by: yongari (before style changes), jkim

Add more chipset revision IDs.

Obtained from: OpenBSD

Add BCM5701 A0/B0 CRC bug workaround. Magic values taken from Linux driver.

Fix style(9).

Pointed out by: many

Add PHY DSP code for BCM5755M.

Obtained from: OpenBSD

- Fix BCM5754 support found in Dell PowerEdge SC440.
- Move some PHY bug detections from brgphy.c to if_bge.c.
- Do not penalize working PHYs.
- Re-arrange bge_flags roughly by their categories.
- Fix minor style(9) nits.

PR: kern/107257
Obtained from: OpenBSD
Tested by: Mike Hibler <mike at flux dot utah dot edu>

Correct the comment describing the BGE_PCISTATE_PCI_BUSSPEED bit.
It had the sense of the bit reversed.

Re-enable MSI support for those chips on which it is believed to work
properly.

Correct the BGE_CHIPID_BCM5750_B0 constant.

MFC after: 1 week

- Remove stale VPD support and its comment and get device name from VPD API.
- Do not repeatedly read vendor/device IDs while probing.
- Remove redundant bzero(3) for softc. device_get_softc(9) does it for free[1].

Reviewed by: glebius
Suggested by: glebius[1]

Add MSI support to the bge driver. I tested this on a Dell SC1435
running an i386 kernel, and it worked fine.

Fix support for certain 575x/578x chips. This consists of the following:

- Use the appropriate register writing method when reseting the chip
- Program the descriptor DMA engine correctly.
- More reliably detect certain chips and their features.

Also add some low-level debugging tools to help future work on this driver.

Submitted by: David Christenson (proof of concept changes)
Sponsored by: www.UIA.net

- Add BGE_FLAG_JUMBO flag which idicates jumbo frame capability. Some day we
may be able to support jumbo frames for BCM5714 and BCM5780.
- Rename BGE_IS_5705_OR_BEYOND() to BGE_IS_5705_PLUS() for consistency.

Use bge_flags to save chipset family and remove dead code while I am here.

Simplify statistics updates, remove redundant register reads, and add
discarded RX packets to input error for BCM5705 or newer chipset as the others.
Unfortunately we cannot do the same for output errors because ifOutDiscards
equivalent register does not exist. While I am here, replace misleading and
wrong BGE_RX_STATS/BGE_TX_STATS with BGE_MAC_STATS. They were reversed but
worked accidently.

- Instead of if_watchdog/if_timer interface use our own timer
that piggybacks on bge_tick() callout.
- Lock bge_tick() using callout_init_mtx().

Remove 3Com 985 deviceid that is really ti(4).

Submitted by: erwin

Add support to bge(4) to not break IPMI support when the driver attaches
to it. Try to co-operate with the IPMI/ASF firmware accessing the PHY.
One we get link we don't mess with the PHY. If we do then over time
the NIC will go off line. It would be nice if we could tell if IPMI
was enabled on the chip but I can't figure out a reliable way to do
that. The scheme I tried worked on a Dell PE850 but not on an HP machine.
So we assume any NIC that has ASF capability needs to deal with it.

The code was inspired by the support in Linux from kernel.org and Broadcom.
Broadcom did give me some info. but it is rather limited and is mostly
just what is in the Linux driver. Thanks to the numerous people that
helped debug the many prior versions and that I didn't break other
bge(4) HW.

Reviewed by: several people
Tested by: even more

Resolve "firmware handshake" error on 5752.

Approved by: ps
MFC after: 2 weeks

/tmp/cvsleYf6y

Pack several boolean fields into single bge_flags field.

Recognize the 5750 C2.

Obtained from: OpenBSD (brad)

- Recognize more device IDs adding support for BCM5754, BCM5755,
BCM5787 based NICs.
- Recognize BCM5703 B0 ASIC.
- Rewrite the jumbo capability matching macro, so that chips known
to work are listed there. [*]

[*] I'm still not sure about this. Probably more corrections
will be done to this macro after discussion with davidch@
and brad@OpenBSD.

Obtained from: OpenBSD (brad)

Possess some work from OpenBSD, with some local additions.

- Add more device IDs, ASIC revisions and chip IDs.
- Rewrite a bit code that picks the description for device.
- Introduce several macros to shorten quirks for bugs and
features.[*]
- Use some magic values, that OpenBSD has successfully
possessed from Linux (Broadcom supplied) driver.
- Remove disabled code that tried to access VPD.

[*] The macro that matches Jumbo capable NICs is
rewritten to preserve our current behavior. I
need clarify whether our or theirs is correct.

PR: 68351 (and may be others)
Obtained from: OpenBSD, brad@ mostly

u_intXX -> uintXX

Correct an obvious typo.

MFC after: 1 week

1) Fix link state detection for cards operating in TBI mode (fiber ones)
2) add missing bus_dmamap_sync() call in bge_intr()

Tested by: Husnu Demir <hdemir AT metu DOT edu DOT tr>
Approved by: glebius (mentor)
MFC after: 3 days

Be ready to a case when not a constant number of segments is returned
by bus_dmamap_load_mbuf_sg() on jumbo buffer allocation.

Reviewed by: scottl, gallatin

- Count packets discarded by RX/TX MAC (cause of FIFO overflow, etc)
as input/output interface errors.
- Keep values of rx/tx discards & tx collisions inside struct bge_softc.
So we can keep statistic across ifconfig down/up runs (cause bringing
bge up will reset chip).

Approved by: glebius (mentor)
MFC after: 1 week

Don't base the number of jumbo segments on page size, instead base it on the
fact that jumbo desriptors are defined to have 3 segments.

Found by: Coverity Prevent(tm)

Use device_printf() and if_printf() rather than printf() and axe
bge_unit from the softc.

Requested by: marius

Since BGE_MBX_TX_HOST_PROD0_LO register is write-only to software,
we can cache its value in the softc. Eliminates one PCI register
write per call to bge_start().

A 1.8% speedup for UDP_RR test on my old box.

Obtained from: NetBSD(jonathan) via delphij

Add bge(4) support for big-endian architectures(part 1/2).
- Give up endianess support and switch to native-endian format for
accessing hardware structures. In fact embedded processor for
BCM57xx is big-endian architure(MIPS) and it requires native-endian
format for NIC structures.The NIC performs necessary byte/word
swapping depending on programmed endian type.
- With above changes all htole16/htole32 calls were gone.
- Remove bge_vhandle member in softc and changed to use explicit
register access. This may add additional performance penalty
that than that of previous memory access. But most of the access
is performed on initialization phase(e.g. RCB setup), it would be
negligible.

Due to incorrect use of bus_dma(9) in bge(4) it still panics sparc64
system in device detach path. The issue would be fixed in next patch.

Reviewed by: jkim (initial version)
Silence from: ps
Tested by: glebius
Obtained from: NetBSD via OpenBSD

A big rewrite of receive Jumbo frame handling. Remove the local Jumbo
cluster allocator, that wasn't MPSAFE. Instead, utilize our new generic
UMA jumbo cluster allocator. Since UMA gives us a 9k piece that is contigous
in virtual memory, but isn't contigous in physical memory we need to handle
a few segments. To deal with this we utilize Tigon chip feature - extended
RX descriptors, that can handle up to four DMA segments for one frame.

Details:

o Remove bge_alloc_jumbo_mem(), bge_free_jumbo_mem(),
bge_jalloc(), bge_jfree() functions.
o Remove SLIST heads, bge_jumbo_tag, bge_jumbo_map from softc.
o Use extended RX BDs for Jumbo receive producer ring, and
initialize it appropriately.
o New bge_newbuf_jumbo():
- Allocate an mbuf with Jumbo cluster with help of m_cljget().
- Load the cluster for DMA with help of bus_dmamap_load_mbuf_sg().
- Assert that we got 3 segments in the DMA mapping.
- Fill in these 3 segments into the extended RX descriptor.

Recognize Broadcom BCM5752 chip, that can be found in HP DC7600.

PR: kern/88940
Submitted by: Alexander Hausner

Introduce polling(4) capability for bge(4).

Submitted by: Oleg Bulyzhin <oleg rinet.ru>

Stop embedding struct ifnet at the top of driver softcs. Instead the
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.

This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.

Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.

Reviewed by: sobomax, sam

Add PCI ID for BCM5789.

Submitted by: S. Aeschbacher

Support the 5714C

Submitted by: John Cagle <john dot cagle at hp dot com>

Adding new device ID for BCM5751M support.

Submitted by: FUJITA Kazutoshi <fujita at soum dot co dot jp>
Reviewed by: sam (mentor)

Start each of the license/copyright comments with /*-, minor shuffle of lines

Add support for the 5721 which seems to be similar to the 5750/5751.

Tested by: Vivek Khera vivek at khera dot org

Whitespace cleanup.

Add support for the BCM5750/5751. Unfortunately the documentation
I have from Broadcom does not give much information on these devices,
so the Broadcom Linux driver was used for clues to what these chips
support. It turns out they are similar to the 5705 with the 5751
being the PCI-Express version and needing special work-arounds and
settings.

Add some special case code to fix a problem with the BCM5704 in TBI (fiber)
mode. The 5704 apparently has some s00p3r s33kr1t registers for setting
the advertisement of pause frame ability (i.e flow control) when in
autoneg mode. If we don't set these registers correctly, we may not
be able to negotiate a proper link with some switches. (Symptom is that
the NIC reports the link as up (PCS synched) but no traffic can be
exchanged.)

PR: kern/67598

Add support for BCM5705K

Submitted by: candy@kgc.co.jp
PR: kern/67110

Add the PCI ID for yet another bge chip: the Altima 1002.

Submitted by: Pavel Gubin <pg@rainbow.ie.tusur.ru>

o add locking
o mark isr MPSAFE

Supported by: FreeBSD Foundation

Add support for the Broadcom BCM5788 (just another entry to the PCI
device ID list, probably a 5705 ASIC).

Submitted by: Marcel Prisi <marcel@virtua.ch>

On Dell boxes such as the PE2650 we need to disable 3 led mode for the
link LED to work.

Reviewed by: wpaul
Obtained from: Linux driver

Fix a typo. BGE_HCC_TX_MAX_COAL_BDS_INT is at offset 0x3C24, not 0x3C34

Add support for the Broadcom BCM5901 and BCM5901 rev A2 chips.
These are 10/100 only NICs found on the IBM Thinkpad R40E and
G40. These seem to be based on the BCM5705 MAC but with a PHY
that doesn't support 1000Mbps modes.

Submitted by: Igor Sviridov <sia@nest.org>

Remove alpha vtophys() hack from if_bgereg.h and clean up unneeded
#includes formerly required to pull in vtophys support, since we
don't need them anymore.

Convert bge(4) to use busdma. I have not tested this on anything
besides x86 yet since I don't have access to a non-x86 FreeBSD
box at the moment. Volunteers welcome.

Add support for the BCM5705 and its ilk. Changes:

- 5705 doesn't support jumbo frames
- Statistics must be read from registers
- RX return ring must be capped at 512 entries
- Omit initialization of certain device blocks
- Acknowledge link change interrupts by setting the 'link changed'
bit in the status register (used to have no effect)
- Remember to toggle the MI completion bit too
- Set the mbuf low watermark differently (on-chip memory buffers,
not BSD mbufs)
- Don't enable Ethernet@WireSpeed feature for certain 5705 chip revs
- Add additional PCI IDs for 5705 and 5782 parts
- Add a forgotten 5704 PCI ID

Most changes ripped kicking and screaming from the Broadcom linux driver.
Thanks to Paul Saab for sanity testing. (My lack of sanity has been
confirmed.)

- Make this work with PAE.
- atomically load and clear the status block so we dont miss an
update.
Submitted by: jdp

Approved by: re (scottl)

- Change the full Asic revision defines to CHIPID to better since the
ASIC revision is really the major number of the CHIPID. Also store
the chipid, asic rev and chip revision in the softc for later use.

- The write twice to send producer index workaround only applies to
the 5700_BX chips, so only do it there.
Requested by: jdp

- Do not initalize the LED's to 0x00. The default configuration
the chip comes up in should yeild proper operation of the LED's.
Confirmed by: John Cagle <john.cagle@hp.com>

Approved by: re (blanket)

- Change the short hand representation of the various ASIC revisions
- Implement the ONEDMA_AT_ONCE workaround as described in the
5703/5704 eratta documents.
Obtained from: NetBSD & Broadcom documentation

Add untested support for the Broadcom 5704.

Obtained from: NetBSD

Obtain the media type from the shared memory and only use the eeprom
as a fallback.

Don't reference the maxlen and flags fields in the ring control blocks
as separate 16-bit entities. Some of the ring control blocks are
in NIC memory, so they must be referenced using 32-bit accesses.
Smaller accesses have been observed to fail under some conditions.
This caused the rings to be set up wrong, leading to writes by the
card outside of the intended bounds of the rings. This problem was
diagnosed by Michael Barthelow. Don Bowman submitted a patch which
fixed the problem using a slightly different approach.

Reference ring control blocks in NIC memory using a pointer to
volatile.

Parenthesize the BGE_HOSTADDR macro definition properly.

MFC after: 3 days

network interface driver changes:

o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls

Reviewed by: many
Approved by: re

Fix instances of macros with improperly parenthasized arguments.

Verified by: md5

Fix a typo in BGE_BIGENDIAN_INIT.

Add support for the BCM5702x chips.

Reviewed by: jdp
MFC after: 1 week

Add support for the BCM5703x chips. I do not have one of these
cards to test; however the submitter reports that this patch works
with the on-board interface on the IBM x235 server.

Submitted by: Jung-uk Kim <jkim@niksun.com>
MFC after: 1 month

Recognize the Altima AC9100 chip, which is used in current versions
of the Netgear GA302-T. I changed the symbolic names in the
submitter's patch to reflect the part number of the chip instead
of the board.

PR: kern/38988
Submitted by: Brad Chapman <chapmanb@arches.uga.edu>
MFC after: 2 days

Work around what appears to be a chip bug in the BCM5701 that shows
up when operating in PCI-X mode. For some received packets there is
data corruption in the first few bytes in that case. Aligning the
packet buffer eliminates the corruption. With this fix, the code
that offsets the packet buffer up by 2 bytes to align the payload is
disabled for BCM5701s operating in PCI-X mode. On the i386, which
permits unaligned accesses, the payload is left unaligned. On other
platforms, the packet is copied after reception to force alignment
of the payload. Obviously, this work-around reduces performance in
those cases (BCM5701 plus PCI-X) where it is in effect.

MFC after: 3 days

Try to sort out the correct way to generate async link state change
interrupts. This is a bit harder than it needs to be because there's
more than one way to generate link attentions, at least one of which
does not work on the BCM5700, but does on the 5701.

For the 5701, we can safely use the 'link changed' bit in the status
block, and we enable link change attentions in the mac event register.
For the 5700, we have to use MII interrupts, which require checking
the MAC status register rather than the status block. This requires
doing an extra register access on each interrupt which I'd prefer to
avoid, but them's the breaks. Testing with both a 3c996-T and 3c996B-T
shows that we do in fact detect the link going up and down properly
on cable insertions/disconnections.

Also, avoid twiddling the autopoll enable bit in the MI mode register
when doing a PHY read. I think this coupled with the other changes
will stop the interrupt storms Paul Saab has been harassing me about.
Manually setting the link to 100baseTX full duplex seems to work ok
for me. (I'm typing over the 3c996B-T right now.)

Lastly, teach the driver how to recognize a 3c996B-SX by checking
the hardware config word in the EEPROM in order to detect the media.
We attach 5701 fiber cards correctly now, but I haven't verified that
they send/receive packets yet since I don't have a second fiber
interface at home. (I know that fiber 5700 cards work, so I'm
keeping my fingers crossed.)

Teach the bge driver about the BCM5701 (specifically, the 3Com
3c996B-T, with the 5701 rev B5 ASIC). One thing that confuses me
still is that the 'link state change' bit in the status block seems
to change state an awful lot. I have a workaround for this in place
now, but it needs more investigation. For the moment though, this
is enough to get the driver to work with this card.

Add support for the Netgear GA302T 10/100/1000 adapter. Given that
it's a 32-bit card, it's quite nice for $75.

MFC after: 3 days

Add device driver support for the Broadcom BCM570x family of gigabit
ethernet controllers. This adds support for the 3Com 3c996-T, the
SysKonnect SK-9D21 and SK-9D41, and the built-in gigE NICs on
Dell PowerEdge 2550 servers. The latter configuration hauls ass:
preliminary measurements show TCP speeds of over 900Mbps using
only normal size frames.

TCP/IP checksum offload, jumbo frames and VLAN tag insertion/stripping
are supported, as well as interrupt moderation.

Still need to fix autonegotiation support for 1000baseSX NICs, but
beyond that, driver is pretty solid.