summaryrefslogtreecommitdiffstats
path: root/sys/dev/re
Commit message (Collapse)AuthorAgeFilesLines
* MFC: r287768, r290566, r290946marius2015-12-271-17/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Although it doesn't make a whole lot of sense to enable RX and TX before their initial configuration is done, it turns out that r281337 (MFCed to stable/10 in r285177) has the inverse effect on some older chips. Moreover, as with newer chips before, two chips seemingly identical according to their MAC revisions may behave differently in this regard, with most working but a few not, making changes extremely hard to test. Closer inspection of the corresponding Linux code suggests that RX and TX should only be enabled after their initial configuration with RTL8168G and later chips, i. e. RTL8106E{,US}, RTL8107E, as well as RTL8168{EP,G,GU,H}, so limit the new code path to these. [1] - Distinguish between RTL8168H and RTL8107E, with the latter being the 10/100-Mbit/s-only variant of the former. - For MAC variants that can only do Fast Ethernet at a maximum, ensure that we don't advertise Gigabit Ethernet speed. - In re_stop(), do the inverse of re_init_locked() and enable RXDV gate on RTL8168G and later chips again, matching what Linux does. - With the latter in place, it turns out that WOL previously only worked by accident with RTL8168G and later chips when the interface actually was brought up. This is due to the fact that with these MAC variants, RXDV gate needs be disabled for WOL to work. So in re_setwol() do just that when IFCAP_WOL is requested. - Add preliminary support for RTL8168H and RTL8107E, with the latter being the 10/100-Mbit/s-only variant of the former.
* MFC: r271864marius2015-12-271-1/+1
| | | | Move rl(4) to dev/rl.
* MFC: r281337marius2015-07-051-9/+5
| | | | | | | | | | | | Don't enable RX and TX before their initial configuration is done, i. e. after setting up interrupt moderation but before turning interrupts on. This matches what Realtek's r8168 Linux driver does as of version 8.039.00 and fixes problems with certain incarnations of certain MAC revisions like the interface requiring an extra up/down-cycle after boot to start working or DMA configuration not being adhered to. PR: 193743, 197535 Approved by: re (kib)
* MFC r273359:yongari2014-10-281-0/+6
| | | | | | | It seems multicast filtering of RTL8168F does not work. Workaround the silicon bug by accepting any multicast packets. PR: 193488
* MFC r265943:yongari2014-05-161-15/+10
| | | | | | | | | Disable TX IP/TCP/UDP checksum offloading for RTL8168C/RTL8168CP. Previously only TX IP checksum offloading was disabled but it's reported that TX checksum offloading for UDP datagrams with IP options also generates corrupted frames. Reporter's controller is RTL8168CP but I guess RTL8168C also have the same issue since it shall share the same core.
* MFC: r261531marius2014-02-231-7/+24
| | | | | | | | | - Implement the RX EARLYOFF and RXDV GATED bits as done by RealTek's Linux driver as iof version 8.037.00 for RTL8168{E-VL,EP,F,G,GU} and RTL8411B. This makes reception of packets work with the RTL8168G (HW rev. 0x4c000000) in my Shuttle DS47. - Consistently use RL_MSI_MESSAGES. In joint forces with: yongari
* MFH: sync the netmap code with the one in HEADluigi2014-02-181-3/+2
| | | | | (enhanced VALE switch, netmap pipes, emulated netmap mode). See details in the log for svn 261909.
* MFC r257306:yongari2013-11-041-0/+2
| | | | | Add preliminary support for RTL8168EP. Approved by: re (delphij)
* MFC r257305:yongari2013-11-041-2/+20
| | | | | | | | | Add preliminary support for RTL8168G, RTL8168GU and RTL8411B. RTL8168GU has two variants(GMII and MII) but it uses the same chip revision id. Driver checks PCI device id of controller and sets internal capability flag(i.e. jumbo frame and link speed down in WOL). Approved by: re (delphij)
* MFC r256828:yongari2013-11-041-0/+2
| | | | | Add preliminary support for RTL8106E PCIe FastEthernet. Approved by: re (delphij)
* r256827:yongari2013-11-041-2/+3
| | | | | | Correct MAC revision bits. Previously it always cleared bit 20 and bit 21. Approved by: re (delphij)
* Correct comment typos.pluknet2013-06-281-5/+5
|
* use netmap_rx_irq() / netmap_tx_irq() to handle interrupts inluigi2013-04-301-7/+3
| | | | | | netmap mode, removing the logic from individual drivers. (note: if_lem.c not updated yet due to some other pending modifications)
* Disable TX IP header checksum offloading on RL_HWREV_8168CP. Theyongari2013-03-131-2/+4
| | | | | | | controller generates wrong checksummed frame if the IP packet has IP options. Submitted by: Alexander Bluhm via brad@openbsd
* Mechanically substitute flags from historic mbuf allocator withglebius2012-12-041-6/+6
| | | | malloc(9) flags in sys/dev.
* Remove duplicate const specifiers in many drivers (I hope I got all ofdim2012-11-051-2/+2
| | | | | | | | | | | | | | | | | | | | them, please let me know if not). Most of these are of the form: static const struct bzzt_type { [...list of members...] } const bzzt_devs[] = { [...list of initializers...] }; The second const is unnecessary, as arrays cannot be modified anyway, and if the elements are const, the whole thing is const automatically (e.g. it is placed in .rodata). I have verified this does not change the binary output of a full kernel build (except for build timestamps embedded in the object files). Reviewed by: yongari, marius MFC after: 1 week
* Switch some PCI register reads from using magic numbers to using the namesgavin2012-09-191-2/+2
| | | | | | defined in pcireg.h MFC after: 1 week
* Align the PCI Express #defines with the style used for the PCI-Xgavin2012-09-181-4/+4
| | | | | | | | | | | | | | | | | #defines. This also has the advantage that it makes the names more compact, iand also allows us to correct the non-uniform naming of the PCIM_LINK_* defines, making them all consistent amongst themselves. This is a mostly mechanical rename: s/PCIR_EXPRESS_/PCIER_/g s/PCIM_EXP_/PCIEM_/g s/PCIM_LINK_/PCIEM_LINK_/g When this is MFC'd, #defines will be added for the old names to assist out-of-tree drivers. Discussed with: jhb MFC after: 1 week
* Use array notation for consistency.emaste2012-08-131-2/+2
|
* Fix size of the bcopy when extracting ethernet addresskevlo2012-06-251-1/+1
| | | | Obtained from: DragonFly
* Make sure we don't dereference a null pointerkevlo2012-05-111-4/+5
|
* Do not toggle IFCAP_TSO4 if we would also do TSO6. Given the driver doesbz2012-04-241-1/+1
| | | | | | | | not currently announce/support TSO6 that cannot happen. Clean it up anyway for consistency. Reviewed by: yongari MFC after: 1 week
* Prefer RL_GMEDIASTAT register to RGEPHY_MII_SSR register toyongari2012-02-281-13/+13
| | | | | | | | | | | | | | | | | | | | extract a link status of PHY when parent driver is re(4). RGEPHY_MII_SSR register does not seem to report correct PHY status on some integrated PHYs used with re(4). Unfortunately, RealTek PHYs have no additional information to differentiate integrated PHYs from external ones so relying on PHY model number is not enough to know that. However, it seems RGEPHY_MII_SSR register exists for external RealTek PHYs so checking parent driver would be good indication to know which PHY was used. In other words, for non-re(4) controllers, the PHY is external one and its revision number is greater than or equal to 2. This change fixes intermittent link UP/DOWN messages reported on RTL8169 controller. Also, mii_attach(9) is tried after setting interface name since rgephy(4) have to know parent driver name. PR: kern/165509
* A bunch of netmap fixes:luigi2012-02-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USERSPACE: 1. add support for devices with different number of rx and tx queues; 2. add better support for zero-copy operation, adding an extra field to the netmap ring to indicate how many buffers we have already processed but not yet released (with help from Eddie Kohler); 3. The two changes above unfortunately require an API change, so while at it add a version field and some spares to the ioctl() argument to help detect mismatches. 4. update the manual page for the two changes above; 5. update sample applications in tools/tools/netmap KERNEL: 1. simplify the internal structures moving the global wait queues to the 'struct netmap_adapter'; 2. simplify the functions that map kring<->nic ring indexes 3. normalize device-specific code, helps mainteinance; 4. start exploring the impact of micro-optimizations (prefetch etc.) in the ixgbe driver. Use 'legacy' descriptors on the tx ring and prefetch slots gives about 20% speedup at 900 MHz. Another 7-10% would come from removing the explict calls to bus_dmamap* in the core (they are effectively NOPs in this case, but it takes expensive load of the per-buffer dma maps to figure out that they are all NULL. Rx performance not investigated. I am postponing the MFC so i can import a few more improvements before merging.
* Use correct Config registers for RTL8139 family. Unlike RTL8168 andyongari2012-02-251-26/+43
| | | | | | | | | | | | | RTL810x family , RTL8139 has different register map for Config registers. While here, follow the lead of re(4) in WOL configuration. - Disable WOL_UCAST and WOL_MCAST capabilities by default. - Config5 register write does not need to unlock EEPROM access on RTL8139 family but unlocking EEPROM access does not affect its operation and make it consistent with re(4). Reported by: Matt Renzelmann mjr <> cs dot wisc dot edu
* For RTL8168/8111D controller, make sure to wake PHY from power downyongari2012-02-141-1/+6
| | | | mode. Otherwise, PHY access times out under certain conditions.
* Fix a logic error which resulted in putting PHY into sleep when WOLyongari2012-01-191-1/+1
| | | | | is active. If WOL is active driver should not put PHY into sleep. This change makes WOL work on RTL8168E.
* Free allocated jumbo buffers when controller is stopped.yongari2012-01-171-2/+14
|
* Use a RX DMA tag to free loaded RX DMA maps.yongari2012-01-171-1/+1
| | | | Previously it used a TX DMA tag.
* add netmap support for "em", "lem", "igb" and "re".luigi2011-12-051-0/+43
| | | | | | | | | | | | | | On my hardware, "em" in netmap mode does about 1.388 Mpps on one card (on an Asus motherboard), and 1.1 Mpps on another card (PCIe bus). Both seem to be NIC-limited, because i have the same rate even with the CPU running at 150 MHz. On the "re" driver the tx throughput is around 420-450 Kpps on various (8111C and the like) chipsets. On the Rx side performance seems much better, and i can receive the full load generated by the "em" cards. "igb" is untested as i don't have the hardware.
* To save more power, switch to 10/100Mbps link when controller isyongari2011-11-231-4/+76
| | | | | | | | put into suspend/shutdown. Old PCI controllers performed that operation in firmware but for RTL8111C or newer controllers, it's responsibility of driver. It's not clear whether the firmware of RTL8111B still downgrades its speed to 10/100Mbps so leave it as it was.
* Make sure to stop TX MAC before freeing queued TX frames.yongari2011-11-231-5/+37
| | | | | | For RTL8111DP, check if the TX MAC is active by reading RL_GTXSTART register. For RTL8402/8168E-VL/8168F/8411, wait until TX queue is empty.
* Disable accepting frames in re_stop() to put RX MAC into idle state.yongari2011-11-231-3/+15
| | | | | | | | | | | | | | | | | | Because there is no reliable way to know whether RX MAC is in stopped state, rejecting all frames would be the only way to minimize possible races. Otherwise it's possible to receive frames while stop command execution is in progress and controller can DMA the frame to freed RX buffer during that period. This was observed on recent PCIe controllers(i.e. RTL8111F). While this change may not be required on old controllers it wouldn't make negative effects on old controllers. One side effect of this change is disabling receive so driver reprograms RL_RXCFG to receive WOL frames when it is put into suspend or shutdown. This should address occasional 'memory modified free' errors seen on recent RealTek controllers.
* Perform media change after setting IFF_DRV_RUNNING flag. Without it,yongari2011-11-221-2/+2
| | | | | | driver would ignore the first link state update if controller already established a link such that it would have to take additional link state handling in re_tick().
* Writing access to RL_CFG5 register also requires EEPROM writeyongari2011-11-221-5/+6
| | | | | | | | | | | | | access. While I'm here, enable WOL through magic packet but disable waking up system via unicast, multicast and broadcast frames. Otherwise, multicast or unicast frame(e.g. ICMP echo request) can wake up system which is not probably wanted behavior on most environments. This was not known as problem because RL_CFG5 register access had not effect until this change. The capability to wake up system with unicast/multicast frames are still set in driver, default off, so users who need that feature can still activate it with ifconfig(8).
* - There's no need to overwrite the default device method with the defaultmarius2011-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.
* Add preliminary support for RTL8168/8111F PCIe Gigabit ethernet.yongari2011-11-171-1/+3
| | | | H/W donated by: RealTek Semiconductor Corp.
* Add preliminary support for second generation RTL8105E PCIeyongari2011-11-171-0/+2
| | | | | | FastEthernet. H/W donated by: RealTek Semiconductor Corp.
* Disable PCIe ASPM (Active State Power Management) for allyongari2011-11-161-1/+21
| | | | | | | | | controllers. More and more RealTek controllers started to implement EEE feature. Vendor driver seems to load a kind of firmware for EEE with additional PHY fixups. It is known that the EEE feature may need ASPM support. Unfortunately there is no documentation for EEE of the controller so enabling ASPM may cause more problems.
* Add missing driver lock in SIOCSIFCAP handler.yongari2011-11-161-1/+3
|
* Add preliminary support for RTL8411 PCIe Gigabit ethernet withyongari2011-11-161-0/+2
| | | | | | integrated card reader. H/W donated by: RealTek Semiconductor Corp.
* Add preliminary support for RTL8402 PCIe FastEthernet withyongari2011-11-161-0/+2
| | | | | | integrated card reader. H/W donated by: RealTek Semiconductor Corp.
* Sprinkle some const.marius2011-11-021-6/+6
|
* Close a race where SIOCGIFMEDIA ioctl get inconsistent link status.yongari2011-10-171-1/+1
| | | | | | | | Because driver is accessing a common MII structure in mii_pollstat(), updating user supplied structure should be done before dropping a driver lock. Reported by: Karim (fodillemlinkarimi <> gmail dot com)
* Add new device id of D-Link DGE-530T Rev. C controller. DGE-503Tyongari2011-07-301-0/+2
| | | | | | | | Rev A1 and B1 is supported by sk(4) but the DGE-530T Rev. C controller is re-branded RealTek 8169 controller. PR: kern/159116 Approved by: re (kib)
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls tojhb2011-03-231-4/+4
| | | | pci_find_cap() instead.
* Add initial support for RTL8401E PCIe Fast Ethernet.yongari2011-02-161-1/+6
| | | | PR: 154789
* Disable TX IP checksum offloading for RTL8168C controllers. Theyongari2011-02-041-4/+19
| | | | | | | | | | | | | | | | controller in question generates frames with bad IP checksum value if packets contain IP options. For instance, packets generated by ping(8) with record route option have wrong IP checksum value. The controller correctly computes checksum for normal TCP/UDP packets though. There are two known RTL8168/8111C variants in market and the issue I observed happened on RL_HWREV_8168C_SPIN2. I'm not sure RL_HWREV_8168C also has the same issue but it would be better to assume it has the same issue since they shall share same core. RTL8102E which is supposed to be released at the time of RTL8168/8111C announcement does not have the issue. Tested by: Konstantin V. Krotov ( kkv <> insysnet dot ru )
* Add support for RTL8105E PCIe Fast Ethernet controller. It seemsyongari2011-01-261-1/+7
| | | | | | | | | | | | | | the controller has a kind of embedded controller/memory and vendor applies a large set of magic code via undocumented PHY registers in device initialization stage. I guess it's a firmware image for the embedded controller in RTL8105E since the code is too big compared to other DSP fixups. However I have no idea what that magic code does and what's purpose of the embedded controller. Fortunately driver seems to still work without loading the firmware. While I'm here change device description of RTL810xE controller. H/W donated by: Realtek Semiconductor Corp.
* Do not use interrupt taskqueue on controllers with MSI/MSI-Xyongari2011-01-261-32/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | capability. One of reason using interrupt taskqueue in re(4) was to reduce number of TX/RX interrupts under load because re(4) controllers have no good TX/RX interrupt moderation mechanism. Basic TX interrupt moderation is done by hardware for most controllers but RX interrupt moderation through undocumented register showed poor RX performance so it was disabled in r215025. Using taskqueue to handle RX interrupt greatly reduced number of interrupts but re(4) consumed all available CPU cycles to run the taskqueue under high TX/RX network load. This can happen even with RTL810x fast ethernet controller and I believe this is not acceptable for most systems. To mitigate the issue, use one-shot timer register to moderate RX interrupts. The timer register provides programmable one-shot timer and can be used to suppress interrupt generation. The timer runs at 125MHZ on PCIe controllers so the minimum time allowed for the timer is 8ns. Data sheet says the register is 32 bits but experimentation shows only lower 13 bits are valid so maximum time that can be programmed is 65.528us. This yields theoretical maximum number of RX interrupts that could be generated per second is about 15260. Combined with TX completion interrupts re(4) shall generate less than 20k interrupts. This number is still slightly high compared to other intelligent ethernet controllers but system is very responsive even under high network load. Introduce sysctl variable dev.re.%d.int_rx_mod that controls amount of time to delay RX interrupt processing in units of us. Value 0 completely disables RX interrupt moderation. To provide old behavior for controllers that have MSI/MSI-X capability, introduce a new tunable hw.re.intr_filter. If the tunable is set to non-zero value, driver will use interrupt taskqueue. The default value of the tunable is 0. This tunable has no effect on controllers that has no MSI/MSI-X capability or if MSI/MSI-X is explicitly disabled by administrator. While I'm here cleanup interrupt setup/teardown since re(4) uses single MSI/MSI-X message at this moment.
OpenPOWER on IntegriCloud