summaryrefslogtreecommitdiffstats
path: root/sys/dev/xl
Commit message (Collapse)AuthorAgeFilesLines
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls tojhb2011-03-231-1/+1
| | | | pci_find_cap() instead.
* Allocate the DMA memory shared between the host and the controller asmarius2011-03-111-4/+4
| | | | | | coherent. MFC after: 2 weeks
* Add flow control for 3C905B and newer controllers. Note, theseyongari2010-11-141-6/+19
| | | | | | controllers support RX pause only. Reviewed by: marius
* Correct an inverted check in r213893.marius2010-11-051-1/+1
|
* Convert the PHY drivers to honor the mii_flags passed down and convertmarius2010-10-151-18/+14
| | | | | | | | | | | | | | | | | | | | | | | 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
* Implement basic WOL support. Note, not all xl(4) controllersyongari2010-08-232-10/+80
| | | | | | support WOL. Some controllers require additional 3-wire auxiliary remote wakeup connector to draw power. More recent xl(4) controllers may not need the wakeup connector though.
* Move xl_reset() to xl_init_locked(). This will make driveryongari2010-08-231-6/+3
| | | | | | | | | | | | | | | | initialize controller from a known good state. Previously driver used to issue controller reset while TX/RX DMA are in progress. I guess resetting controller in active TX/RX DMA cycle is to ensure stopping I/Os in xl_shutdown(). I remember some buggy controllers didn't respond with stop command if controller is under high network load at the time of shutdown so resetting controller was the only safe way to stop the I/Os. However, from my experiments, controller always responded with stop command under high network load so I think it's okay to remove the xl_reset() in device_shutdown handler. Resetting controller also will clear configured RX filter which in turn will make WOL support hard because driver have to reprogram RX filter in WOL handler as well as setting station address.
* Remove unnecessary controller reinitialization by checkingyongari2010-08-231-5/+11
| | | | IFF_DRV_RUNNING flag.
* Clean up SIOCSIFCAP handler and allow RX checksum offloading couldyongari2010-08-231-31/+38
| | | | be controlled by user.
* cardbus -> CardBusimp2010-01-031-2/+2
|
* Make xl(4) build with Tx checksum offload.yongari2009-07-091-4/+4
| | | | | PR: kern/136409 Approved by: re (kib)
* Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/rwatson2009-06-261-4/+4
| | | | | | | | | | | | | 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
* When user_frac in the polling subsystem is low it is going to busy theattilio2009-05-301-9/+16
| | | | | | | | | | | | | | | | | | | | | 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
* remove dead code with reference to IFQ_HANDOFFkmacy2009-04-271-26/+0
|
* To make it easy whether xl(4) missed Tx completion interrupt checkyongari2009-04-211-3/+19
| | | | | | | number of queued packets in watchdog timeout handler. If there are no queued packets just print a informational message and return without resetting controller. Also fix to invoke correct Tx completion handler as 3C905B needs different handler.
* Clear IFF_DRV_OACTIVE flag if one of queued packets was transmitted.yongari2009-04-211-2/+6
| | | | | | | | | | | Previously it used to clear the flag only when the transmit queue is empty which may slow down Tx performance. While I'm here check whether driver is running and whether we can queue more packets in if_start handler. This fixes occasional watchdog timeouts. Reported by: xer < xernet <> hotmail dot it > Tested by: xer < xernet <> hotmail dot it >
* remove now-redunant cardbus attachment.imp2009-03-091-1/+0
|
* Move the xl driver form sys/pci to sys/dev/xl for consistency.imp2008-08-102-0/+4109
OpenPOWER on IntegriCloud