summaryrefslogtreecommitdiffstats
path: root/sys/dev/fxp
Commit message (Collapse)AuthorAgeFilesLines
* Remove unnecessary #if as the software workaround for PCI protocolyongari2012-03-281-8/+5
| | | | | | | | | violation should be activated unless the system is cold-booted after updating EEPROM. The PCI protocol violation happens only when established link is 10Mbps so the workaround should be updated whenever link state change is detected. Previously the workaround was activated only when user checks current media status with ifconfig(8).
* Load entire EEPROM contents in device attach time and verifyyongari2012-03-283-23/+59
| | | | | | | | | | | whether the checksum of EEPROM is valid or not. Because driver heavily relies on EEPROM information when it selectively enables features/workarounds, it would be helpful to know whether driver sees valid EEPROM. While I'm here remove all other EEPROM accesses since the entire EEPROM is loaded at device attach time. MFC after: 2 weeks
* Partially revert r223608 and selectively allow microcode loadingyongari2012-03-282-5/+18
| | | | | | | | | | | | | | | | | | for 82550C. For 82550 controllers this change restores CPUSaver microcode loading. Due to silicon bug on 82550 and 82550C with server extension, these controllers seem to require CPUSaver microcode to receive fragmented UDP datagrams. However the microcode shouldn't be used on client featured 82550C as it locks up the controller. In addition, client featured 82550C does not have the silicon bug. Also clear temporary memory used for microcode loading since the same memory area is used for other commands. While I'm here use 82550C in probe message instead of generic 82550. Reported by: Andreas Longwitz <longwitz <> incore de> Tested by: Andreas Longwitz <longwitz <> incore de> MFC after: 2 weeks
* Do not change current media when driver is already running. Ifyongari2012-03-191-3/+3
| | | | | | | | | | | | driver is running driver would have already completed flow control configuration. This change removes unnecessary media changes in controller reconfiguration cases such that it does not trigger link reestablishment for configuration change requests like promiscuous mode change. Reported by: Many Tested by: Mike Tancsa <mike <> sentex dot net> MFC after: 1 week
* Fix white space nits.yongari2012-03-141-7/+7
|
* fxp(4) does not handle deferred dma map loading. Tellyongari2012-03-141-3/+5
| | | | | bus_dmamap_load(9) that it should return immediately with error when there are insufficient mapping resources.
* Minor indenting divot...imp2012-01-251-1/+1
|
* TCP header size is represented by number of 32bits words.yongari2011-12-191-1/+1
| | | | | | | | | | | | Fix the TCP header size calculation such that makes TSO engine cache all header(ethernet/IP/TCP) bytes to its internal buffer. While here, remove extra pull up for TCP payload. Unlike some em(4) controllers, fxp(4) does not require such work around for TSO. The two limitations are ethernet/IP/TCP header size should be less than or equal to the size of controller's internal buffer(80 bytes) and these header information should be found in the first fragment of a TSO frame.
* - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHYmarius2011-10-082-0/+237
| | | | | | | | | | | | | | drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h.
* Enable CPUSaver D102 E-step microcode loading for 82551 revisionyongari2011-06-271-0/+2
| | | | 0x10.
* Disable microcode loading for 82550 and 82550C controllers. Loadingyongari2011-06-271-0/+4
| | | | | | | | | | the microcode caused SCB timeouts. Linux driver does not allow microcode loading for these controllers and jfv also confirmed that there is no need to do and it shouldn't. PR: kern/103332 Additional confirmation from: jfv MFC after: 1 week
* - Remove attempts to implement setting of BMCR_LOOP/MIIF_NOLOOPmarius2011-05-031-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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@
* Normally fxp(4) does not receive bad frames but promiscuous modeyongari2011-03-281-2/+2
| | | | | | | | | | | | | | | | makes controller to receive bad frames and i82557 will also receive bad frames since fxp(4) have to receive VLAN oversized frames. If fxp(4) encounter DMA overrun error, the received frame size would be 0 so the actual frame size after checksum field extraction the length would be negative(-2). Due to signed/unsigned comparison used in driver, frame length check did not work for DMA overrun frames. Correct this by casting it to int. While I'm here explicitly check DMA overrun error and discard the frame regardless of result of received frame length check. Reported by: n_hibma Tested by: n_hibma MFC after: 1 week
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls tojhb2011-03-231-3/+3
| | | | pci_find_cap() instead.
* - Allocate the DMA memory shared between the host and the controller asmarius2011-02-261-4/+4
| | | | | coherent. - Update a comment to no longer reference Alpha.
* Fix a regression introduced in r215906. The change made in r215906yongari2011-02-151-1/+3
| | | | | | | | | | | caused link re-negotiation whenever application joins or leaves a multicast group. If driver is running, it would have established a link so there is no need to start re-negotiation. The re-negotiation broke established link which in turn stopped multicast application working while re-negotiation is in progress. PR: kern/154667 MFC after: 1 week
* If RX lockup workaround is enabled, fxp(4) will periodically resetyongari2010-12-021-4/+6
| | | | | | | | | | | | | | | | | | | | the controller to workaround silicon bug of i82557. Each reset will re-establish link which in turn triggers MII status change callback. The callback will try to reconfigure controller if the controller is not i82557 to enable flow-control. This caused endless link UP/DOWN when the workaround was enabled on non-i82557 controller. To fix the issue, apply RX lockup workaround only for i82557. Previously it blindly checked undocumented EEPROM location such that it sometimes enabled the workaround for other controllers. At this time, only i82557 is known to have the silicon bug. This fixes a regression introduced in r215906 which enabled flow control support for all controllers except i82557. Reported by: Karl Denninger (karl <> denninger dot net) Tested by: Karl Denninger (karl <> denninger dot net) MFC after: 3 days
* Fix and implement missing parts of flow control support. This also removesmarius2010-11-263-35/+74
| | | | | | | | the dev.fxp.%d.noflow tunable as the same effect can now be achieved with ifconfig(8) by setting the flowcontrol media option as desired (besides the tunable never having a chance to actually enable flow control support so far). In joint forces with: yongari
* - Sprinkle const on tables.marius2010-11-232-26/+14
| | | | | - Remove an alpha remnant. - Minor comment and style fixes.
* Add TSO support over VLAN for i82550/i82551. Controller requiresyongari2010-10-241-3/+12
| | | | | | | | | VLAN hardware tagging to make TSO work over VLAN. So if VLAN hardware tagging is disabled explicitly clear TSO over VLAN. While I'm here allow disabling VLAN TX checksum offloading. Tested by: Liudas < liudasb <> centras dot lt > MFC after: 10 days
* Convert the PHY drivers to honor the mii_flags passed down and convertmarius2010-10-151-4/+8
| | | | | | | | | | | | | | | | | | | | | | | 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
* Make sure to not use stale ip/tcp header pointers. The ip/tcpyongari2010-10-141-0/+2
| | | | | | | | | | | header parser uses m_pullup(9) to get access to mbuf chain. m_pullup(9) can allocate new mbuf chain and free old one if the space left in the mbuf chain is not enough to hold requested contiguous bytes. Previously drivers can use stale ip/tcp header pointer if m_pullup(9) returned new mbuf chain. Reported by: Andrew Boyer (aboyer <> averesystems dot com) MFC after: 10 days
* If controller received bad frames make sure to update newly addedyongari2010-05-141-2/+7
| | | | | | | | | | | | | | | | | | | RFA. Also drop frames that have either CRC error or alignment error. Normally bad frames are not received at all. But controllers running in promiscuous mode will receive bad frames. 82557 will also receive bad frames to receive VLAN oversized frames. While I'm here mark RNR condition if driver happen to see RNR in RFA status and restart RU to receive frames again. Because driver checks all received frames in RX loop, RNR condition could be set in the middle of RX processing. Just relying on RNR interrupt was not enough. This change fixes "Memory modified after free" issue when fxp(4) is running as a member of if_bridge(4). Tested by: Larry Baird <lab <> gta dot com> MFC after: 5 days
* Dont' allow dma map load deferring. fxp(4) is not able to handleyongari2010-05-141-1/+1
| | | | EINPROGRESS.
* Controller updates RFA via DMA so driver needs synchronization.yongari2010-05-141-2/+2
| | | | Add missing BUS_DMASYNC_POSTWRITE and BUS_DMASYNC_PREREAD.
* Export hardware MAC statistics through sysctl node. Previouslyyongari2010-05-093-78/+242
| | | | | | | | | | | | | | | | | | | | | | fxp(4) already used to extract most hardware MAC statistics but it didn't show them. With this change, all MAC statistics counters are exported. Because there are a couple of new counters for 82558 and 82559, enable extended MAC statistics functionality to get these counters. Accoring to public data sheet, 82559 MAC statistics return 24 DWORD counters(3 counters are unknown at this moment) so increase MAC counter structure to meet the MAC statistics block size. The completion of MAC counter dump is now checked against FXP_STATS_DR_COMPLETE status code which is appended at the end of status block. Previously fxp(4) ignored the status of the FXP_SCB_COMMAND_CU_DUMPRESET command. fxp(4) does not wait for the completion of pending command before issuing FXP_SCB_COMMAND_CU_DUMPRESET. Instead it skips the command and try it next time. This scheme may show better performance but there is chance to loose updated counters after stopping controller. So make sure to update MAC statistics in fxp_stop(). While I'm here move sysctl node creation to fxp_sysctl_node(). Tested by: Larry Baird < lab <> gta dot com >
* 8255x configure command requires number of bytes of configurationyongari2010-05-071-4/+13
| | | | | | | | | | | | | | | | table. The default size of the configuration table was 22 bytes. To use extended feature of 82550/82551 the configuration table size was expanded to 32 bytes. The added configuration for 82550/82551 specifies VLAN hardware tagging and IPSec configuration as well as TCO. To make configuration easier fxp(4) used a configuration template and the template was copied to configuration table. After that, some parameters of the configuration table was changed depending on controller type and operation mode. However the size of template was 22 bytes so some configuration parameters were not properly initialized on 82550/82551. Fix this by increasing the template size. For 82557, 82558 and 82559 the size of the configuration is still 22 bytes.
* It seems controller has two types of promiscuous control, one foryongari2010-05-071-1/+1
| | | | | | | | | | | unicast and the other for multicast. To receive multicast frames that host didn't join in promiscuous mode, driver have to set promiscuous mode for multicast frames as well. The Open Source Software Developer Manual for i8255x was not clear how to handle promiscuous mode. PR: kern/145905 MFC after: 5 days
* With r206844, CSUM_TCP is also set for CSUM_TSO case. Modifyyongari2010-04-191-54/+52
| | | | | drivers to take into account for the change. Basically CSUM_TSO should be checked before checking CSUM_TCP.
* It seems some 82559ER controllers do not support Rx checksumyongari2009-09-281-2/+5
| | | | | | | | | offloading. Datasheet said nothing about the limitation of 82559ER except WOL. Explicitly disable Rx checksum offloading for controllers that is known to lack the capability. PR: kern/138135 Tested by: Gooderum, Mark < mgooderum <> websense dot com >
* Revert previous commit and add myself to the list of people who shouldphk2009-09-081-1/+0
| | | | know better than to commit with a cat in the area.
* Add necessary include.phk2009-09-081-0/+1
|
* Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/rwatson2009-06-261-2/+2
| | | | | | | | | | | | | IF_ADDR_UNLOCK() across network device drivers when accessing the per-interface multicast address list, if_multiaddrs. This will allow us to change the locking strategy without affecting our driver programming interface or binary interface. For two wireless drivers, remove unnecessary locking, since they don't actually access the multicast address list. Approved by: re (kib) MFC after: 6 weeks
* For ICH based fxp(4) controllers treat them as 82559 compatibles.yongari2009-06-212-69/+93
| | | | | | | | | | | | | | To detect which controller is ICH based one, add a new member variable ich to struct fxp_ident and move the struct to if_fxpvar.h. Since I've faked controller revision, don't allow microcode loading for ICH based controllers. With this change all ICH based controllers will have WOL and Rx checksum offload capability. PR: kern/135451 Tested by: Alexey Shuvaev ( shuvaev <> physik dot uni-wuerzburg dot de ), pluknet ( pluknet <> gmail dot com ), Gary Jennejohn ( gary.jennejohn <> freenet dot de )
* Overhaul fxp(4) multicast filter programming. fxp(4) hardwares doyongari2009-06-212-134/+38
| | | | | | | | | | | | | | | | | | | not allow multicast filter programming when controller is busy to send/receive frames. So it used to mark need_mcsetup bit and defer multicast filter programming until controller becomes idle state. To detect when the controller is idle fxp(4) relied on Tx completion interrupt with NOP command and fxp_start_body and fxp_intr_body had to see whether pending multicast filter programming was requested. This resulted in very complex logic and sometimes it did not work as expected. Since the controller should be in idle state before any multicast filter modifications I changed it to reinitialize the controller whenever multicast filter programming is required. This is the same way what OpenBSD and NetBSD does. Also I added IFF_DRV_RUNNING check in ioctl handler so controller would be reinitialized only if it is absolutely needed. With this change I guess we can remove fxp(4) DELAY hack in ifioctl for IPv6 case.
* Always check fxp(4) is running, see if it can accept frames fromyongari2009-06-211-3/+10
| | | | | | | | upper stack in fxp_start_body(). fxp(4) drops driver lock in Rx path so check the fxp(4) is still running after reacquiring driver lock in Rx path. Also don't invoke fxp_intr_body if fxp(4) is not running. With this change there is no need to set suspend bit in device attach phase.
* Don't blindly enable Rx lock-up workaround. Newer chips do not needyongari2009-06-212-1/+9
| | | | | | the Rx lock-up workaround. Obtained from: NetBSD
* Due to possible PCI bus lock-up issues fxp(4) didn't perform fullyongari2009-06-211-1/+5
| | | | | | | | | hardware reset in attach phase. Selective reset does not clear configured parameters so I think full hardware reset is required. To prevent PCI bus lock-up, do selective reset first which will get off the controller from PCI bus and request software reset after selective reset. Software reset will unmask interrupts so disable it after the reset.
* Introduce Rx mbuf dma tag and use it in Rx path. Previously it usedyongari2009-06-212-44/+73
| | | | | | | | | | | | | | common mbuf dma tag for both Tx and Rx path but Rx buffer should have single DMA segment and maximum buffer size of the segment should be less than MCLBYTES. fxp(4) also have to check Tx completion status which was updated by DMA so we need BUS_DMASYNC_PREREAD and BUS_DMASYNC_POSTWRITE synchronization in Tx path. Fix all misuse of bus_dmamap_sync(9) in fxp(4). I guess this change shall fix occasional driver breakage in PAE environments. While I'm here add error messages of dma tag/buffer creation and correct messages.
* Controller will dma SCB command status for a given command andyongari2009-06-101-13/+14
| | | | | | | | | driver should read updated status back after issuing a SCB command. To send a command to controller and read updated status back, driver should synchronize both memory read and write operations with device. Fix bus_dmamap_sync operation specifier used in fxp_dma_wait() by adding both memory read and memory write operations.
* When user_frac in the polling subsystem is low it is going to busy theattilio2009-05-301-7/+14
| | | | | | | | | | | | | | | | | | | | | CPU for too long period than necessary. Additively, interfaces are kept polled (in the tick) even if no more packets are available. In order to avoid such situations a new generic mechanism can be implemented in proactive way, keeping track of the time spent on any packet and fragmenting the time for any tick, stopping the processing as soon as possible. In order to implement such mechanism, the polling handler needs to change, returning the number of packets processed. While the intended logic is not part of this patch, the polling KPI is broken by this commit, adding an int return value and the new flag IFCAP_POLLING_NOCOUNT (which will signal that the return value is meaningless for the installed handler and checking should be skipped). Bump __FreeBSD_version in order to signal such situation. Reviewed by: emaste Sponsored by: Sandvine Incorporated
* Don't blindly set IP packet length from interface MTU in TSO case.yongari2009-04-131-1/+2
| | | | | | | | | | Remote host can advertise smaller MSS than that of sender so upper stack might have adjusted the MSS which in turn generates IP packets that are less size than that of interface MTU. Reported by: Bjoern Koenig ( bkoenig <> alpha-tierchen dot de ) Tested by: Bjoern Koenig ( bkoenig <> alpha-tierchen dot de ) MFC after: 3 days
* remove now-redunant cardbus attachment.imp2009-03-091-1/+0
|
* writereg returns an int.imp2009-02-051-2/+3
|
* Always check whether dma map is valid before unloading the map.yongari2009-01-081-1/+2
| | | | | When fxp(4) intializes Rx buffers for the first time, there is no loaded dma map so attempting to unload it is an invalid operation.
* It seems that we don't need to reserve a TBD to set total TCPyongari2008-12-181-4/+4
| | | | | | payload length in TSO case. Leaving unused TBD also seem to cause SCB timeouts under certain conditions when TSO/non-TSO traffics are active at the same time.
* mutex.h is needed here. It got it by namespace pollution.yongari2008-12-081-0/+2
| | | | Pointed out by: bde
* Add VLAN hardware tag insertion/stripping support. Tx/Rx checksumyongari2008-12-022-2/+29
| | | | | | | | | | | offload for VLAN frames are also supported. The VLAN hardware assistance is available only on 82550/82551 based controllers. While I'm here change the confusing name of bit1 in byte 22 of configuration block to vlan_drop_en. The bit controls whether hardware strips VLAN tagged frame or not. Special thanks to wpaul who sent valuable VLAN related information to me. Tested on: i386, sparc64
* Make sure to clear PMDR register by writing back power managementyongari2008-12-021-5/+4
| | | | | | | events. Just reading PMDR register was not enough to have fxp(4) immuninize against received magic packets during system boot. Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de >
* Add basic WOL support for 82550/82551/82558 and 82559 basedyongari2008-11-273-11/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | controllers. ICH based controllers are treated as 82559. 82557, earlier revision of 82558 and 82559ER have no WOL capability. o WOL support requires help of a firmware so add check whether hardware is capable of handling magic frames by reading EEPROM. o Enable accepting WOL frames only when hardware is about to suspend or shutdown. Previously fxp(4) used to allow receipt of magic frame under normal operation mode which could cause hardware hang if magic frame is received by hardware. Datasheet clearly states driver should not allow WOL frames under normal operation mode. o Disable WOL frame reception in device attach so have fxp(4) immunize against system hang which can be triggered by magic packets when the hardware is not in fully initialized state. o Don't reset all hardware configuration data in fxp_stop() otherwise important configuration data is lost and this would reset WOL configuration to default state which in turn cause hardware hang on receipt of magic frames. To fix the issue, preserve hardware configuration data by issuing a selective reset. o Explicitly disable interrupts after issuing selective reset as reset may unmask interrupts. Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de >
OpenPOWER on IntegriCloud