aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/bge
Commit message (Collapse)AuthorAgeFilesLines
...
* Make if_ierrors updated whenever any of the following counters arePyun YongHyeon2012-03-122-0/+8
| | | | | | | | | | | | | | | | 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> Notes: svn path=/head/; revision=232850
* Show PCI bus speed and width as well as running mode of PCI-XPyun YongHyeon2012-03-122-7/+59
| | | | | | | | | | 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. Notes: svn path=/head/; revision=232849
* Add workaround for PCI-X BCM5704 controller that live behindPyun YongHyeon2012-03-122-3/+68
| | | | | | | | | | | | 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 > Reviewed by: jhb Notes: svn path=/head/; revision=232848
* After r232403, DMA transactions does not cross 4GB boundary forPyun YongHyeon2012-03-102-37/+6
| | | | | | | all PCI devices. Remove driver workaround for 4GB boundary issue. Notes: svn path=/head/; revision=232766
* Remove PAE special-case 2GB DMA boundary and always use a 4GB boundaryJohn Baldwin2012-03-091-4/+0
| | | | | | | | | now that DMA tags in PAE kernels support 4GB boundaries. Reviewed by: yongari Notes: svn path=/head/; revision=232727
* Call bge_add_sysctls() early and especially before bge_can_use_msi() soMarius Strobl2012-02-071-2/+2
| | | | | | | | r230337 actually has a chance of working and doesn't always unconditionally disable the use of MSIs. Notes: svn path=/head/; revision=231159
* Oops, fix logic error introduced in r230337.Pyun YongHyeon2012-01-191-1/+1
| | | | Notes: svn path=/head/; revision=230338
* Rename dev.bge.%d.msi_disable to dev.bge.%d.msi which matchesPyun YongHyeon2012-01-192-7/+7
| | | | | | | | | enable/disable and default it to on. Suggested by: jhb Notes: svn path=/head/; revision=230337
* Introduce a tunable that disables use of MSI.Pyun YongHyeon2012-01-172-0/+10
| | | | | | | Non-zero value will use INTx. Notes: svn path=/head/; revision=230286
* Destroy DMA tag for jumbo RX buffer in device detach.Pyun YongHyeon2011-12-131-0/+2
| | | | Notes: svn path=/head/; revision=228480
* BCM5720 performance tweak from Broadcom.Pyun YongHyeon2011-12-132-3/+18
| | | | | | | | | | | 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. Submitted by: Geans Pin < geanspin <> broadcom dot com > Notes: svn path=/head/; revision=228479
* - There's no need to overwrite the default device method with the defaultMarius Strobl2011-11-221-5/+1
| | | | | | | | | | | | | one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID. Notes: svn path=/head/; revision=227843
* Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.Ed Schouten2011-11-071-1/+1
| | | | | | | | | The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static. Notes: svn path=/head/; revision=227309
* Disable updating InputDiscards counter for BCM5717, BCM5718,Pyun YongHyeon2011-10-281-2/+24
| | | | | | | | BCM5719 A0 and BCM5720 A0 and add comment why driver does not try to read it. Notes: svn path=/head/; revision=226872
* Add initial BCM5720 support.Pyun YongHyeon2011-10-282-29/+87
| | | | | | | | | | Many thanks to Broadcom for continuing support of FreeBSD. Submitted by: Geans Pin at Broadcom (initial version) H/W donated by: Broadcom Notes: svn path=/head/; revision=226871
* Define BGE_FW_HB_TIMEOUT_SEC and remove one more magic value.Pyun YongHyeon2011-10-272-1/+4
| | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=226867
* Rename hard-coded value 1 << 14 with BGE_RX_CPU_DRV_EVENT.Pyun YongHyeon2011-10-272-3/+7
| | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=226866
* Rename BGE_FW_DRV_ALIVE/BGE_FW_PAUSE to BGE_FW_CMD_DRV_ALIVE/BGE_FW_CMD_PAUSE.Pyun YongHyeon2011-10-272-4/+10
| | | | | | | | Also add more firmware commands(not used yet). No functional changes. Notes: svn path=/head/; revision=226864
* SRAM offset 0x0C04 is used by driver to inform the IPMI/ASF firmwarePyun YongHyeon2011-10-262-6/+20
| | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=226821
* Offset 0x6810 is RX-RISC event register. Rename BGE_CPU_EVENT withPyun YongHyeon2011-10-262-6/+7
| | | | | | | | BGE_RX_CPU_EVENT for readability. Additionally define BGE_TX_CPU_EVENT for TX-RSIC event register(BCM570[0-4] only). Notes: svn path=/head/; revision=226820
* Define MAC address mail box and use it instead of usingPyun YongHyeon2011-10-262-2/+4
| | | | | | | hard-coded value. Notes: svn path=/head/; revision=226815
* Rename definition of BGE_SOFTWARE_GENCOMM_* to more readable ones.Pyun YongHyeon2011-10-262-23/+24
| | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=226814
* BCM5719 cannot handle DMA requests for DMA segments that havePyun YongHyeon2011-10-262-0/+10
| | | | | | | | | | | | 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. Notes: svn path=/head/; revision=226807
* Broadcom says BCM5755 or higher and BCM5906 have short DMA bug.Pyun YongHyeon2011-10-261-3/+4
| | | | | | | Apply workaround to these controllers. Notes: svn path=/head/; revision=226806
* It is known that all Broadcom controllers have 4GB boundary DMAPyun YongHyeon2011-10-261-4/+2
| | | | | | | bug. Apply workaround to all controllers. Notes: svn path=/head/; revision=226805
* Make CPMU handle GPHY power down control on controllers that havePyun YongHyeon2011-10-261-1/+2
| | | | | | | CPMU capability. Notes: svn path=/head/; revision=226804
* Fix long standing bge_sysctl_debug_info() issues.Pyun YongHyeon2011-10-261-7/+16
| | | | | | | | | | | 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. Notes: svn path=/head/; revision=226770
* Whitespace nits.Pyun YongHyeon2011-10-251-5/+5
| | | | Notes: svn path=/head/; revision=226749
* Correctly disable jumbo frame support for BCM5719 A0.Pyun YongHyeon2011-05-151-1/+1
| | | | Notes: svn path=/head/; revision=221974
* Add initial BCM5719 support. TSO and jumbo frame was intentionallyPyun YongHyeon2011-05-122-12/+88
| | | | | | | | | | 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 Notes: svn path=/head/; revision=221818
* Since r117657, bge(4) does not enable buffer manager for BCM5705 orPyun YongHyeon2011-05-091-34/+47
| | | | | | | | | | | | | | | | | | newer controllers. However, all data sheet I have access has no indication that buffer manager should not be touched on these controllers. It seems the buffer manager always runs on BCM5705 or newer controllers. Some controller(e.g. BCM5719) needs other buffer manager configuration so driver should enable buffer manager for all controllers. Both Linux and OpenBSD/NetBSD use the same approach. This change polls enable bit of block to know whether specified block was really stopped as well as enabling buffer manager for all controllers in driver initialization. Obtained from: NetBSD Notes: svn path=/head/; revision=221712
* Enable Ethernet@WireSpeed for BCM5718/BCM57765 family. While I'mPyun YongHyeon2011-05-052-7/+7
| | | | | | | | here inverse meaning of PHY flag as Ethernet@WireSpeed is enabled for most PHYs. Notes: svn path=/head/; revision=221468
* Add initial BCM57765 family support. The BCM57765 family seems toPyun YongHyeon2011-05-042-6/+59
| | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=221445
* - Remove attempts to implement setting of BMCR_LOOP/MIIF_NOLOOPMarius Strobl2011-05-031-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (reporting IFM_LOOP based on BMCR_LOOP is left in place though as it might provide useful for debugging). For most mii(4) drivers it was unclear whether the PHYs driven by them actually support loopback or not. Moreover, typically loopback mode also needs to be activated on the MAC, which none of the Ethernet drivers using mii(4) implements. Given that loopback media has no real use (and obviously hardly had a chance to actually work) besides for driver development (which just loopback mode should be sufficient for though, i.e one doesn't necessary need support for loopback media) support for it is just dropped as both NetBSD and OpenBSD already did quite some time ago. - Let mii_phy_add_media() also announce the support of IFM_NONE. - Restructure the PHY entry points to use a structure of entry points instead of discrete function pointers, and extend this to include a "reset" entry point. Make sure any PHY-specific reset routine is always used, and provide one for lxtphy(4) which disables MII interrupts (as is done for a few other PHYs we have drivers for). This includes changing NIC drivers which previously just called the generic mii_phy_reset() to now actually call the PHY-specific reset routine, which might be crucial in some cases. While at it, the redundant checks in these NIC drivers for mii->mii_instance not being zero before calling the reset routines were removed because as soon as one PHY driver attaches mii->mii_instance is incremented and we hardly can end up in their media change callbacks etc if no PHY driver has attached as mii_attach() would have failed in that case and not attach a miibus(4) instance. Consequently, NIC drivers now no longer should call mii_phy_reset() directly, so it was removed from EXPORT_SYMS. - Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe(). The purpose of that function is to perform the common steps to attach a PHY driver instance and to hook it up to the miibus(4) instance and to optionally also handle the probing, addition and initialization of the supported media. So all a PHY driver without any special requirements has to do in its bus attach method is to call mii_phy_dev_attach() along with PHY-specific MIIF_* flags, a pointer to its PHY functions and the add_media set to one. All PHY drivers were updated to take advantage of mii_phy_dev_attach() as appropriate. Along with these changes the capability mask was added to the mii_softc structure so PHY drivers taking advantage of mii_phy_dev_attach() but still handling media on their own do not need to fiddle with the MII attach arguments anyway. - Keep track of the PHY offset in the mii_softc structure. This is done for compatibility with NetBSD/OpenBSD. - Keep track of the PHY's OUI, model and revision in the mii_softc structure. Several PHY drivers require this information also after attaching and previously had to wrap their own softc around mii_softc. NetBSD/OpenBSD also keep track of the model and revision on their mii_softc structure. All PHY drivers were updated to take advantage as appropriate. - Convert the mebers of the MII data structure to unsigned where appropriate. This is partly inspired by NetBSD/OpenBSD. - According to IEEE 802.3-2002 the bits actually have to be reversed when mapping an OUI to the MII ID registers. All PHY drivers and miidevs where changed as necessary. Actually this now again allows to largely share miidevs with NetBSD, which fixed this problem already 9 years ago. Consequently miidevs was synced as far as possible. - Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that weren't explicitly converted to support flow control before. It's unclear whether flow control actually works with these but typically it should and their net behavior should be more correct with these changes in place than without if the MAC driver sets MIIF_DOPAUSE. Obtained from: NetBSD (partially) Reviewed by: yongari (earlier version), silence on arch@ and net@ Notes: svn path=/head/; revision=221407
* Correct spelling in comments.Marius Strobl2011-05-021-2/+2
| | | | | | | Submitted by: brucec Notes: svn path=/head/; revision=221344
* Fix an logic bug which caused jumbo buffers to not be synced.Marius Strobl2011-05-021-1/+1
| | | | | | | | | Reported and tested by: Michael Moll MFC after: 3 days Notes: svn path=/head/; revision=221343
* Add initial jumbo frame support for BCM5714/BCM5715 and BCM5780.Pyun YongHyeon2011-04-052-17/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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) Notes: svn path=/head/; revision=220368
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls toJohn Baldwin2011-03-231-3/+3
| | | | | | | pci_find_cap() instead. Notes: svn path=/head/; revision=219902
* sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.Matthew D Fleming2011-01-121-1/+1
| | | | | | | Commit the rest of the devices. Notes: svn path=/head/; revision=217323
* Apply DMA address space restriction to controllers that have 4GBPyun YongHyeon2011-01-101-1/+11
| | | | | | | | | | | | | | | DMA boundary bug and runs with PCI-X mode. watchdog timeout was observed on BCM5704 which lives behind certain PCI-X bridge(e.g. AMD 8131 PCI-X bridge). It's still not clear whether the root cause came from that PCI-X bridge or not. The watchdog timeout indicates the issue is in TX path. If the bridge reorders TX mailbox write accesses it would generate all kinds of problems but I'm not sure. This should be revisited. Tested by: Michael L. Squires (mikes <> siralan dot org) Notes: svn path=/head/; revision=217226
* Backout r216973 and r216970. r216973 didn't solve watchdog timeoutPyun YongHyeon2011-01-101-11/+1
| | | | | | | | | | issue seen on PCIX BCM5704 controller. r216970 fixed the issue but the DMA address space restriction was applied to all bge(4) controllers such that it caused unnecessary performance degradation for controllers that have no such issues. Notes: svn path=/head/; revision=217225
* Limit hardware bug workaround to controllers that have 4GB boundaryPyun YongHyeon2011-01-041-1/+4
| | | | | | | | | | bug instead of blindly applying it to all controllers. Pointed out by: marius MFC after: 3 days Notes: svn path=/head/; revision=216973
* Partially revert change made in r212061. r212061 relied onPyun YongHyeon2011-01-041-1/+8
| | | | | | | | | | | | | | | | | | bus_dma(9)'s capability which honors boundary restrictions of DMA tag for dynamic buffers. However it seems this does not work well and it triggered watchodg timeouts on controller that has the hardware bug. It's not clear whether there is still another hardware bug not mentioned in errata. This should be revisited since this change shall make use of bounce buffers which in turn reduces performance a lot on systems that have more than 4GB memory. Reported by: Michael L. Squires (mikes <> siralan dot org) Tested by: Michael L. Squires (mikes <> siralan dot org) MFC after: 3 days Notes: svn path=/head/; revision=216970
* - Remove the remaining support for older (in this case pre-7.0-RELEASE)Marius Strobl2010-11-301-47/+19
| | | | | | | | | | | | | | | versions of FreeBSD. In fact we are already missing a lot of conditional code necessary to support older versions of FreeBSD, including alternatives for vital functionality not yet provided by the respective subsystem back then (see for example r199663). So this change shouldn't actually break this driver on versions of FreeBSD that were supported before. Besides, this driver also isn't maintained as an multi-release version outside of the main repository, so removing the conditional code shouldn't be a problem in that regard either. - Sprinkle some more const on tables. Notes: svn path=/head/; revision=216085
* Move the limiting of the PHY to 10/100 modes of operation due to limitationsMarius Strobl2010-11-141-5/+23
| | | | | | | | | of certain MAC models from brgphy(4) to bge(4) where it belongs. While at it, update the list of models having that restriction to what OpenBSD uses, which in turn seems to have obtained that information from the Linux tg3 driver. Notes: svn path=/head/; revision=215302
* o Flesh out the generic IEEE 802.3 annex 31B full duplex flow controlMarius Strobl2010-11-141-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | support in mii(4): - Merge generic flow control advertisement (which can be enabled by passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD, IFM_FLOW isn't implemented as a global option via the "don't care mask" but instead as a media specific option this. This has the following advantages: o allows flow control advertisement with autonegotiation to be turned on and off via ifconfig(8) with the default typically being off (though MIIF_FORCEPAUSE has been added causing flow control to be always advertised, allowing to easily MFC this changes for drivers that previously used home-grown support for flow control that behaved that way without breaking POLA) o allows to deal with PHY drivers where flow control advertisement with manual selection doesn't work or at least isn't implemented, like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4), by setting MIIF_NOMANPAUSE o the available combinations of media options are readily available from the `ifconfig -m` output - Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so these are understood by ifconfig(8). o Make the master/slave support in mii(4) actually usable: - Change IFM_ETH_MASTER from being implemented as a global option via the "don't care mask" to a media specific one as it actually is only applicable to IFM_1000_T to date. - Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to actually configure manually selected slave mode (like we also do in the PHY specific implementations). - Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it is understood by ifconfig(8). o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4), e1000phy(4) and ip1000phy(4) to use the generic flow control support instead of home-grown solutions via IFM_FLAGs. This includes changing these PHY drivers and smcphy(4) to no longer unconditionally advertise support for flow control but only if the selected media has IFM_FLOW set (or MIIF_FORCEPAUSE is set) and implemented for these media variants, i.e. typically only for copper. o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0 and some IFM_FLAGn. o Switch brgphy(4) to add at least the the supported copper media based on the contents of the BMSR via mii_phy_add_media() instead of hardcoding them. The latter approach seems to have developed historically, besides causing unnecessary code duplication it was also undesirable because brgphy_mii_phy_auto() already based the capability advertisement on the contents of the BMSR though. o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not just BCM5701. Apparently this was a misinterpretation of a workaround in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but this doesn't mean we can't set these as well on other PHYs for manual media selection. o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so IFM_1000_T master mode support now is generally available with all PHY drivers. o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's not applicable there. Reviewed by: yongari (plus additional testing) Obtained from: NetBSD (partially), OpenBSD (partially) MFC after: 2 weeks Notes: svn path=/head/; revision=215297
* Add initial BCM5718 family support. The BCM5718 family includesPyun YongHyeon2010-10-272-69/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=214428
* Use bge_chipid to compare controller ids. r214251 incorrectly usedPyun YongHyeon2010-10-241-3/+3
| | | | | | | | | bge_chiprev. Reported by: Buganini <buganini <> gmail dot com > Notes: svn path=/head/; revision=214292
* Apply the same workaround for SDI flow control used on BCM5906 A1Pyun YongHyeon2010-10-232-5/+9
| | | | | | | | | | | | | 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 > Notes: svn path=/head/; revision=214251
* Add workaround for BCM5906 A1 controller silicon bug. WhenPyun YongHyeon2010-10-222-0/+6
| | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=214219
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-25 05:49:25 +0000