summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_rlreg.h
Commit message (Collapse)AuthorAgeFilesLines
* Consistently use capital letters.yongari2010-04-091-2/+2
|
* Add preliminary support for 8168E/8111E PCIe controller.yongari2010-04-091-0/+3
| | | | | | | While I'm here simplify device description string. Tested by: Michael Beckmann < michael <> apfel dot de > MFC after: 5 days
* Add initial support for RTL8103E PCIe fastethernet.yongari2010-01-271-0/+1
| | | | PR: kern/142974
* Add RTL8168DP/RTL8111DP device id. While I'm here append "8111D" toyongari2009-08-241-0/+1
| | | | | | | | the description of RTL8168D as RL_HWREV_8168D can be either RTL8168D or RTL8111D. PR: kern/137672 MFC after: 3 days
* Adding hardware ID for RTL810x PCIe found on HP Pavilion DV2-1022AX.avatar2009-07-141-0/+1
| | | | | Reviewed by: yongari Approved by: re (kib, kensmith)
* For RTL8139C+ controllers, have controller handle padding shortyongari2009-04-201-0/+1
| | | | | | | | | | | | | checksum offload frames. Software workaround used for broken controllers(RTL8169, RTL8168, RTL8168B) seem to cause watchdog timeouts on RTL8139C+. Introduce a new flag RL_FLAG_AUTOPAD to mark automatic padding feature of controller and set it for RTL8139C+ and controllers that use new descriptor format. This fixes watchdog timeouts seen on RTL8139C+. Reported by: Dimitri Rodis < DimitriR <> integritasystems dot com > Tested by: Dimitri Rodis < DimitriR <> integritasystems dot com >
* Allocating 2 MSI messages do not seem to work on certain controllersyongari2009-02-111-1/+1
| | | | | | | so use just 1 MSI message. This fixes regression introduced in r188381. Tested by: many
* - Add support for 8110SCe part. Some magic registers were taken fromjkim2009-01-201-4/+4
| | | | | | | Linux driver. - Swap hardware revisions for 8110S and 8169S as Linux driver claims. Reviewed by: yongari (early version)
* Retire RL_FLAG_INVMAR bit to match its comment and reality.jkim2009-01-201-1/+0
|
* Sometimes RTL8168B seems to take long time to access GMII registersyongari2009-01-191-0/+1
| | | | | | | | in device attach phase. Double GMII register access timeout value to fix the issue. Reported by: wkoszek Tested by: wkoszek
* It seems that RealTek PCIe controllers require an explicit Tx pollyongari2008-12-171-0/+1
| | | | | | | | | | | | | | | | | | | command whenever Tx completion interrupt is raised. The Tx poll bit is cleared when all packets waiting to be transferred have been processed. This means the second Tx poll command can be silently ignored as the Tx poll bit could be still active while processing of previous Tx poll command is in progress. To address the issue re(4) used to invoke the Tx poll command in Tx completion handler whenever it detects there are pending packets in TxQ. However that still does not seem to completely eliminate watchdog timeouts seen on RealTek PCIe controllers. To fix the issue kick Tx poll command only after Tx completion interrupt is raised as this would indicate Tx is now idle state such that it can accept new Tx poll command again. While here apply this workaround for PCIe based controllers as other controllers does not seem to have this limitation. Tested by: Victor Balada Diaz < victor <> bsdes DOT net >
* For RTL8168C SPIN2 controllers, make sure to take the controlleryongari2008-12-171-0/+3
| | | | | | | | out of sleep mode prior to accessing to PHY. This should fix device attach failure seen on these controllers. Also enable the sleep mode when device is put into sleep state. PR: kern/123123, kern/123053
* Make WOL work on RTL8168B. This controller seems to requireyongari2008-12-111-0/+1
| | | | | | explicit command to enable Rx MAC prior to entering D3. Tested by: Cyrus Rahman <crahman <> gmail DOT com>
* Don't access undocumented register 0x82 on controllers thatyongari2008-12-111-0/+2
| | | | | | | have no such register. While here clear undocumented PHY register 0x0B for RTL8110S. Obtained from: RealTek FreeBSD driver
* Newer RealTek controllers requires setting stop request bit toyongari2008-12-111-0/+2
| | | | terminate active Tx/Rx operation.
* o Implemented miibus_statchg handler. It detects whether re(4)yongari2008-12-081-0/+1
| | | | | | | | | | | | | | | | established a valid link or not. In miibus_statchg handler add a check for established link is valid one for the controller(e.g. 1000baseT is not a valid link for fastethernet controllers.) o Added a flag RE_FLAG_FASTETHER to mark fastethernet controllers. o Added additional check to know whether we've really encountered watchdog timeouts or missed Tx completion interrupts. This change may help to track down the cause of watchdog timeouts. o In interrupt handler, removed a check for link state change interrupt. Not all controllers have the bit and re(4) did not rely on the event for a long time. In addition, re(4) didn't request the interrupt in RL_IMR register. Tested by: rpaulo
* Add 8168D support.yongari2008-12-021-0/+1
| | | | Submitted by: Andrew < andrewwtulloch <> gmail DOT com >
* Make RL_TWISTER_ENABLE a tunable/sysctl. Eliminate it as an option.imp2008-11-021-4/+1
| | | | | | Fix module build. Submitted by: Kostik Belousov
* Add RL_TWISTER_ENABLE option. This enables the magic bits to do longimp2008-10-311-0/+30
| | | | | | | | | cable tuning. This has helped in some installations for hardware deployed by a former employer. Made optional because the lists aren't full of complaints about these cards... even when they were wildly popular. Reviewed by: attilio@, jhb@, trhodes@ (all an older version of the patch)
* Various bus_dma(9) fixes.yongari2008-10-251-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The hardware does not support DAC so limit DMA address space to 4GB. - Removed BUS_DMA_ALLOC_NOW flag. - Created separated Tx buffer and Rx buffer DMA tags. Previously it used to single DMA tag and it was not possible to specify different DMA restrictions. - Apply 4 bytes alignment limitation of Tx buffer. - Apply 8 bytes alignment limitation of Rx buffer. - Tx side bus_dmamap_load_mbuf_sg(9) support. - Preallocate Tx DMA maps as creating DMA maps take very long time on architectures that require real DMA maps. - Adjust guard buffer size to 1522 + 8 as it should include VLAN and additional reserved bytes in Rx buffer. - Plug memory leak in device detach. Previously wrong buffer address was used to free allocated memory. - Added rl_list_rx_init() to clear Rx buffer and cleared the buffer. - Don't destroy DMA maps in rl_txeof() as the DMA map should be reused. There is no reason to destroy/recreate the DMA maps in this driver. - Removed rl_dma_map_rxbuf()/rl_dma_map_txbuf() callbacks. - The hardware does not support descriptor based DMA on Tx side and the Tx buffer address should be aligned on 4 bytes boundary as well as manual padding for short frames. Because of this hardware limitation rl(4) always used to invoke m_defrag(9) to get a 4 bytes aligned single buffer. However m_defrag(9) takes a lot of CPU cycles on slow machines and not all packets need the help of m_defrag(9). Armed with the information, don't invoke m_defrag(9) if the following conditions are true. 1. Buffer is not fragmented. 2. Buffer is aligned on 4 bytes boundary. 3. Manual padding is not necessary. 4. Or padding is necessary but upper stack passed a writable buffer and the space needed for padding is satisfied. This change combined with preallocated DMA maps greatly increased Tx performance of driver on sparc64. - Moved bus_dmamap_sync(9) in rl_start_locked() to rl_encap() and corrected memory synchronization operation specifier of bus_dmamap_sync(9). - Removed bus_dmamap_unload(9) in rl_stop(). There is no need to reload/unload Rx buffer as rl(4) always have to copy from the buffer. It just needs proper bus_dmamap_sync(9) calls before copying the received frame. With this change rl(4) should work on systems with more than 4GB memory. PR: kern/128143
* The number of bits reserved for MSS in RealTek controllers isyongari2008-08-041-0/+8
| | | | | | | 11bits. This limits the maximum interface MTU size in TSO case as upper stack should not generate TCP segments with MSS greater than the limit. Armed with this information, disable TSO if interface MTU is greater than the limit.
* Add driver support for RTL8102E and RTL8102EL which is the secondyongari2008-07-091-0/+2
| | | | | | | | | generation of RTL810x PCIe fast ethernet controller. Note, Tx/Rx descriptor format is different from that of first generation of RTL8101E series. Jumbo frame is not supported for RTL810x family. Tested by: NAGATA Shinya ( maya AT negeta DOT com )
* Add a new RTL8169 variant, 8169SB(L)/8110SB(L).yongari2008-07-021-0/+1
| | | | | Reported by: nork Tested by: nork
* Add basic support for RTL8168C, RTL8168CP, RTL8111C and RTL8111CP.yongari2008-07-021-0/+24
| | | | | | | | | | | | | | | | ATM Tx/Rx checksum offload is supported but TSO and jumbo frame is not yet supported. Because these newer controllers use different descriptor formats, a flag RL_FLAG_DESCV2 flag was introduced to handle that case in Tx/Rx handler. Also newer controllers seems to require to not touch 'enable Tx/Rx bit' in RL_CPLUS_CMD register so don't blindly try to set that bits. Note, it seems that there is still power-saving related issue where driver fails to attach PHY. Rebooting seems to fix that issue but number of required reboots varys. Many thanks to users that helped during developement. I really appreciate their patient and test/feedbacks.
* Instead of allocating variables for each events/hardware flags, useyongari2008-07-021-2/+6
| | | | | | | | | a dedicated flag that represents controller capabilities/events. This will simplify many part of code that requires different workaround for each controller revisions and will enhance readability. While I'm here move PHY wakeup code up before mii_phy_probe() which seems to help to wake PHY in some cases.
* Switch to memory space register mapping over IO space. If thatyongari2008-07-021-0/+2
| | | | mapping fails fall back to traditional IO space access.
* Add another 8139D variant.remko2008-06-161-0/+1
| | | | | | | PR: 124622 Submitted by: Evgeny Zhirnov <jirnov at gmail dot com> Approved by: imp (mentor, implicit) MFC after: 3 days
* Padding more bytes than necessary one broke another variants ofyongari2008-03-311-0/+6
| | | | | | | | PCIe RealTek chips. Only pad IP packets if the payload is less than 28 bytes. Obtained from: NetBSD PR: kern/122221
* For MSI capable hardwares, enable MSI enable bit in RL_CFG2yongari2008-03-231-0/+1
| | | | | register. If MSI was disabled by hw.re.msi_disable tunable expliclty clear the MSI enable bit.
* Don't allow jumbo frame on 8139C+ controller.yongari2008-03-031-0/+2
| | | | While I'm here add a check for minimal MTU length.
* Implement WOL.yongari2008-03-031-1/+39
| | | | Tested by: Fabian Keil ( freebsd-listen AT fabienkeli DOT de )
* Overhaul re(4).yongari2008-01-151-23/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o Increased number of Rx/Tx descriptors to 256 for 8169 GigEs because it's hard to push the hardware to the limit with default 64 descriptors. TSO requires large number of Tx descriptors to pass a full sized TCP segment(65535 bytes IP packet) to hardware. Previously it consumed 32 Tx descriptors, assuming MCLBYTES DMA segment size, to send the TCP segment which means re(4) couldn't queue more than two full sized IP packets. For 8139C+ it still uses 64 Rx/Tx descriptors due to its hardware limitations. With this changes there are (very) small waste of memory for 8139C+ users but I don't think it would affect 8139C+ users for most cases. o Various bus_dma(9) fixes. - The hardware supports DAC so allow 64bit DMA operations. - Removed BUS_DMA_ALLOC_NOW flag. - Increased DMA segment size to 4096 from MCLBYTES because TSO consumes too many descriptors with MCLBYTES DMA segment size. - Tx/Rx side bus_dmamap_load_mbuf_sg(9) support. With these changes the code is more readable than previous one and got a (slightly) better performance as it doesn't need to pass/ decode arguments to/from callback function. - Removed unnecessary callback function re_dmamap_desc() and nuked rl_dmaload_arg structure which was used in the callback. - Additional protection for DMA map load failure. In case of failure reuse current map instead of returning a bogus DMA map. - Deferred DMA map unloading/sync operation for maximum performance until we really need to load new DMA map. If we happen to reuse current map(e.g. input error) there is no need to sync/unload/load again. - The number of allowable Tx DMA segments for a mbuf chains are now 32 instead of magic nseg value. If the number of available Tx descriptors are short enough to send highly fragmented mbuf chains an optimized re_defrag() is called to collapse mbuf chains which is supposed to be much faster than m_defrag(9). re_defrag() was borrowed from ath(4). - Separated Rx/Tx DMA tag from a common DMA tag such that Rx DMA tag correctly uses DMA maps that were created with DMA alignment restriction(8bytes alignments). Tx DMA tag does not have such alignment limitation. - Added additional sanity checks for DMA ring map load failure. - Added additional spare Rx DMA map for graceful handling of Rx DMA map load failure. - Fixed misused bus_dmamap_sync(9) and added missing bus_dmamap_sync(9) in re_encap()/re_txeof()/re_rxeof(). o Enabled TSO again as re(4) have reasonable number of Tx descriptors. o Don't touch DMA address of a Tx descriptor in re_txeof(). It's not needed. o Fix incorrect update of if_ierrors counter. For Rx buffer shortage it should update if_qdrops as the buffer is reused. o Added checks for unsupported H/W revisions and return ENXIO for these hardwares. This is required to remove resource allocation code in re_probe as other drivers do in device probe routine. o Modified descriptor index manipulation macros as it's now possible to have different number of descriptors for Rx/Tx. o In re_start, to save a lock operation, use IFQ_DRV_IS_EMPTY before trying to invoke IFQ_DRV_DEQUEUE. Also don't blindly call re_encap since we already know the number of available Tx descriptors in advance. o Removed RL_TX_DESC_THLD which was used to reserve RL_TX_DESC_THLD descriptors in Tx path. There is no such a limitation mentioned in 8139C+/8169/8110/8168/8101/8111 datasheet and it seems to work ok without reserving RL_TX_DESC_THLD descriptors. o Fix a comment for RL_GTXSTART. The register is 8bits register. o Added comments for 8169/8139C+ hardware restrictions on descriptors. o Removed forward declaration for "struct rl_softc", it's not needed. o Added a new structure rl_txdesc for Tx descriptor managements and a structure rl_rxdesc for Rx descriptor managements. o Removed unused member variable rl_intlock in driver softc. There are still several unused member variables which are supposed to be used to access hardware statistics counters. But it seems that accessing hardware counters were not implemented yet.
* Add another RTL8168 revision 3 which is found on RTL8111-GR Gigabityongari2007-12-081-0/+1
| | | | | | | | | Ethernet Controller. Multicast filtering wasn't tested and needs more expore. While I'm here change complex if statements with switch statement which would improve readability. Reported by: Abdullah Ibn Hamad Al-Marri < wearabnet AT yahoo DOT ca > Tested by: Abdullah Ibn Hamad Al-Marri < wearabnet AT yahoo DOT ca >
* Add the FNW3603TX Planex NIC.remko2007-11-261-0/+5
| | | | | | | PR: 76081 Approved by: imp (mentor) Submitted by: umi at pocke dot org MFC After: 3 days
* Add MSI support.yongari2007-07-241-2/+5
| | | | | | | | | | | | Ever since switching to adaptive polling re(4) occasionally spews watchdog timeouts on systems with MSI capability. This change is minimal one for supporting MSI and re(4) also needs MSIX support for RTL8111C in future. Because softc structure of re(4) is shared with rl(4), rl(4) was touched to use the modified softc. Reported by: cnst Tested by: cnst Approved by: re (kensmith)
* re(4) devices requires an external EEPROM. Depending on models ityongari2007-07-061-0/+2
| | | | | | | | | | | | | | | | | | | would be 93C46(1Kbit) or 93C56(2Kbit). One of differences between them is number of address lines required to access the EEPROM. For example, 93C56 EEPROM needs 8 address lines to read/write data. If 93C56 recevied premature end of required number of serial clock(CLK) to set OP code/address of EEPROM, the result would be unexpected behavior. Previously it tried to detect 93C46, which requires 6 address lines, and then assumed it would be 93C56 if read data was not expected value. However, this approach didn't work in some models/situations as 93C56 requries 8 address lines to access its data. In order to fix it, change EEPROM probing order such that 93C56 is detected reliably. While I'm here change hard-coded address line numbers with defined constant to enhance readability. PR: 112710 Approved by: re (mux)
* Don't reinitialize the hardware if only PROMISC flag was changed.yongari2007-04-181-0/+1
| | | | | | | | | | Previously whenever PROMISC mode turned on/off link renegotiation occurs and it could resulted in network unavailability for serveral seconds.(Depending on switch STP settings it could last several tens seconds.) Reported by: Prokofiev S.P. < proks AT logos DOT uptel DOT net > Tested by: Prokofiev S.P. < proks AT logos DOT uptel DOT net >
* o In re_newbuf() and re_encap() if re_dma_map_desc() aborts the mappingmarius2007-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operation as it ran out of free descriptors or if there are too many segments in the first place, call bus_dmamap_unload() in order to unload the already loaded segments. For trying to map the defragmented mbuf (chain) in re_encap() this introduces re_dma_map_desc() setting arg.rl_maxsegs to 0 as a new failure mode. Previously we just ignored this case, corrupting our view of the TX ring. o In re_txeof(): - Don't clear IFF_DRV_OACTIVE unless there are at least 4 free TX descriptors. Further down the road re_encap() will bail if there aren't at least 4 free TX descriptors, causing re_start() to abort and prepend the dequeued mbuf again so it makes no sense to pretend we could process mbufs again when in fact we won't. While at it replace this magic 4 with a macro RL_TX_DESC_THLD throughout this driver. - Don't cancel the watchdog timeout as soon as there's at least one free TX descriptor but instead only if all descriptors have been handled. It's perfectly normal, especially in the DEVICE_POLLING case, that re_txeof() is called when only a part of the enqueued TX descriptors have been handled, causing the watchdog to be disarmed prematurely. o In re_encap(): - If m_defrag() fails just drop the packet like other NIC drivers do. This should only happen when there's a mbuf shortage, in which case it was possible to end up with an IFQ full of packets which couldn't be processed as they couldn't be defragmented as they were taking up all the mbufs themselves. This includes adjusting re_start() to not trying to prepend the mbuf (chain) if re_encap() has freed it. - Remove dupe initialization of members of struct rl_dmaload_arg to values that didn't change since trying to process the fragmented mbuf chain. While at it remove an unused member from struct rl_dmaload_arg. o In re_start() remove a abandoned, banal comment. The corresponding code was moved to re_attach() some time ago. With these changes re(4) now survives one day (until stopped) of hammering out packets here. Reviewed by: yongari MFC after: 2 weeks
* if_watchdog -> rl_watchdogru2006-12-011-0/+1
|
* Add TSO support.yongari2006-11-211-0/+1
| | | | Tested by: wilko, Pieter de Goeje < pieter AT degoeje DOT nl >
* Use #ifndef __NO_STRICT_ALIGNMENT rather thanyongari2006-11-211-1/+1
| | | | | #if !defined(__i386__) && !defined(__amd64__) for architectures with alignment constraints.
* Another small update to the re(4) driver:wpaul2006-08-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Change the workaround for the autopad/checksum offload bug so that instead of lying about the map size, we actually create a properly padded mbuf and map it as usual. The other trick works, but is ugly. This approach also gives us a chance to zero the pad space to avoid possibly leaking data. - With the PCIe devices, it looks issuing a TX command while there's already a transmission in progress doesn't have any effect. In other words, if you send two packets in rapid succession, the second one may end up sitting in the TX DMA ring until another transmit command is issued later in the future. Basically, if re_txeof() sees that there are still descriptors outstanding, it needs to manually resume the TX DMA channel by issuing another TX command to make sure all transmissions are flushed out. (The PCI devices seem to keep the TX channel moving until all descriptors have been consumed. I'm not sure why the PCIe devices behave differently.) (You can see this issue if you do the following test: plug an re(4) interface into another host via crossover cable, and from the other host do 'ping -c 2 <host with re(4) NIC>' to prime the ARP cache, then do 'ping -c 1 -s 1473 <host with re(4) NIC>'. You're supposed to see two packets sent in response, but you may only see one. If you do 'ping -c 1 -s 1473 <host with re(4) NIC>' again, you'll see two packets, but one will be the missing fragment from the last ping, followed by one of the fragments from this ping.) - Add the PCI ID for the US Robotics 997902 NIC, which is based on the RTL8169S. - Add a tsleep() of 1 second in re_detach() after the interrupt handler is disconnected. This should allow any tasks queued up by the ISR to drain. Now, I know you're supposed to use taskqueue_drain() for this, but something about the way taskqueue_drain() works with taskqueue_fast queues doesn't seem quite right, and I refuse to be tricked into fixing it.
* Fix the following bugs in re(4)wpaul2006-07-301-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Correct the PCI ID for the 8169SC/8110SC in the device list (I added the macro for it to if_rlreg.h before, but forgot to use it.) - Remove the extra interrupt spinlock I added previously. After giving it some more thought, it's not really needed. - Work around a hardware bug in some versions of the 8169. When sending very small IP datagrams with checksum offload enabled, a conflict can occur between the TX autopadding feature and the hardware checksumming that can corrupt the outbound packet. This is the reason that checksum offload sometimes breaks NFS: if you're using NFS over UDP, and you're very unlucky, you might find yourself doing a fragmented NFS write where the last fragment is smaller than the minimum ethernet frame size (60 bytes). (It's rare, but if you keep NFS running long enough it'll happen.) If checksum offload is enabled, the chip will have to both autopad the fragment and calculate its checksum header. This confuses some revs of the 8169, causing the packet that appears on the wire to be corrupted. (The IP addresses and the checksum field are mangled.) This will cause the NFS write to fail. Unfortunately, when NFS retries, it sends the same write request over and over again, and it keeps failing, so NFS stays wedged. (A simple way to provoke the failure is to connect the failing system to a network with a known good machine and do "ping -s 1473 <badhost>" from the good system. The ping will fail.) Someone had previously worked around this using the heavy-handed approahch of just disabling checksum offload. The correct fix is to manually pad short frames where the TCP/IP stack has requested checksum offloading. This allows us to have checksum offload turned on by default but still let NFS work right. - Not a bug, but change the ID strings for devices with hardware rev 0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek, they're both the same device, but 0x30000000 is an earlier silicon spin.
* Properly detect the RTL8168(B?) again. RealTek sent me a bunch of samplewpaul2006-06-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | cards: the chips are all marked "RTL8111B", but they put stickers on the back that say "RTL8168B/8111B". The manual says there's only one HWREV code for both the 8111B and 8168B devices, which is 0x30000000, but the cards they sent me actually report HWREV of 0x38000000. Deciding to trust the hardware in front of me rather than a possibly incorrect manual (it wouldn't be the first time the HWREVs were incorrectly documented), I changed the 8168 revision code. It turns out this was a mistake though: 0x30000000 really is a valid for the 8168. There are two possible reasons for there to be two different HWREVs: 1) 0x30000000 is used only for the 8168B and 0x38000000 is only for the 8111B. 2) There were 8111/8168 rev A devices which both used code 0x30000000, and the 8111B/8168B both use 0x38000000. The product list on the RealTek website doesn't mention the existence of any 8168/8111 rev A chips being in production though, and I've never seen one, so until I get clarification from RealTek, I'm going to assume that 0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only. So, the HWREV code for the 8168 has been put back to 0x30000000, a new 8111 HWREV code has been added, and there are now separate entries for recognizing both devices in the device list. This will allow all devices to work, though if it turns out I'm wrong I may need to change the ID strings
* Add support for the RealTek 8169SC/8110SC and RTL8101E devices. Thewpaul2006-06-261-17/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | latter is a PCIe 10/100 chip. Finally fix the EEPROM reading code so that we can access the EEPROMs on all devices. In order to access the EEPROM, we must select 'EEPROM programming' mode, and then set the EEPROM chip select bit. Previously, we were setting both bits simultaneously, which doesn't work: they must be set in the right sequence. Always obtain the station address from the EEPROM, now that EEPROM reading works correctly. Make the TX interrupt moderation code based on the internal timer optional and turned off by default. Make the re_diag() routine conditional and off by default. When it is on, only use it for the original 8169, which was the only device that that really needed it. Modify interrupt handling to use a fast interrupt handler and fast taskqeueue. Correct the rgephy driver so that it only applies the DSP fixup for PHY revs 0 and 1. Later chips are fixed and don't need the fixup. Make the rgephy driver advertise both 1000_FD and 1000_HD bits in autoneg mode. A couple of the devices don't autoneg correctly unless configured this way.
* Rename device name in the last commit. According to PR, the ID isglebius2006-05-241-2/+2
| | | | | | | more likely to belong to chips of 8168 family. PR: kern/96734 Submitted by: Sven Petai <hadara bsd.ee>
* Add support for RTL8111B chip, that can be found on some mainboards,glebius2006-03-221-0/+2
| | | | | | for example ASUS P5PL2. Tested by: Vadim Frolov <vadim uch.net>
* Only allow the sk(4) driver to attach to revision 2 of the LinkSys EG1032jhb2005-10-141-2/+17
| | | | | | | | cards and teach the re(4) driver to attach to revision 3 cards. Submitted by: Fredrik Lindberg fli+freebsd-current at shapeshifter dot se MFC after: 2 weeks Reviewed by: imp, mdodd
* - Use if_printf() and device_printf() in re(4) and remove rl_unit fromjhb2005-09-291-2/+1
| | | | | | | | | | | | | | | | the softc. - Use callout_init_mtx() and rather than timeout/untimeout in both rl(4) and re(4). - Fix locking for ifmedia by locking the driver in the ifmedia handlers rather than in the miibus functions. (re(4) didn't lock the mii stuff at all!) - Fix some locking in re_ioctl(). Note: the two drivers share the same softc declared in if_rlreg.h, so they had to be change simultaneously. MFC after: 1 week Tested by: several on rl(4), none on re(4)
* Recognize D-Link DGE-528(T) Gigabit as an re(4) device.tobez2005-08-051-0/+5
| | | | | | Submitted by: Andrus Nomm <andrus@members.ee> PR: 76780 MFC After: 1 week
OpenPOWER on IntegriCloud