summaryrefslogtreecommitdiffstats
path: root/sys/dev/fxp
Commit message (Collapse)AuthorAgeFilesLines
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-063-3/+3
|
* Allow fxp(4) cards with a revision id of 0 to use the 82503 serialmux2005-01-041-1/+1
| | | | | | | | | interface as well. This is not an expected revision id per the datasheet, but unfortunately there are such cards out there with a 82557 chipset, and they want to use the 82503. PR: kern/75739 Reported by: Andre Albsmeier <andre.albsmeier@siemens.com>
* Only try to use the 82503 serial interface for the 82557 chipsets. Themux2004-12-201-2/+2
| | | | | | | | | datasheet says it is only valid for such chipsets and shouldn't be used with others. This fixes some 82559 based cards which otherwise only work at 10Mbit. MFC after: 5 days Tested by: krion
* Make interrupt coalescing work on big endian systems.yongari2004-11-171-2/+4
| | | | | | | Also change struct ucode.length to be in number of elements (u_int32_t) to help endian handling. MFC after: 2 weeks
* Add support for the fxp(4) based card in ICH6 (i915) chipsets.mux2004-09-181-0/+1
| | | | | | This is a RELENG_5 candidate. Submitted by: Mike Tancsa <mike@sentex.net>
* Deorbit the fxp tuning hint (hint.fxp.UNIT_NUMBER.ipcbxmit_disable)truckman2004-08-111-26/+4
| | | | | introduced in if_fxp.c revision 1.180. The bug fix committed in revision 1.180 fixed the packet truncation problem.
* Bring in the first chunk of altq driver modifications. This covers themlaier2004-07-021-4/+9
| | | | | | | | | | | following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4), sis(4) and xl(4) More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take a look and tell me if "your" driver is missing, so I can fix this. Tested-by: many No-objection: -current, -net
* Remove the setting of the pci config variables on power state changes.imp2004-06-281-37/+2
| | | | The bus does this now.
* Abstract the locking in fxp(4) a bit more by using macros formux2004-06-022-8/+11
| | | | | mtx_assert() and mtx_owned(), as it is done in other places, for instance proc locking.
* Use the device sysctl tree instead of rolling our own. Some of themux2004-06-022-26/+20
| | | | | | | | | | | sysctls were global (hw.fxp_rnr and hw.fxp_noflow), all of them are now per-device. Sample output of "sysctl dev.fxp0" with this patch, with the standard %foo nodes removed : dev.fxp0.int_delay: 1000 dev.fxp0.bundle_max: 6 dev.fxp0.rnr: 0 dev.fxp0.noflow: 0
* Add missing <sys/module.h> includesphk2004-05-301-0/+1
|
* POLA dictates that VLAN_MTU be enabled by default.yar2004-05-271-1/+7
| | | | | | | | In particular, disabling it was likely to break configurations involving ng_vlan(4) since the latter couldn't control the parent's VLAN_MTU in the way vlan(4) did. Pointed out by: ru
* Those sysctls shouldn't be writtable from inside a jail.pjd2004-05-261-2/+2
|
* Teach fxp(4) to control VLAN_MTU in the hardware.yar2004-05-252-8/+17
| | | | | | | | Now reception of extended frames can be toggled through ioctl(SIOCSIFCAP). The card will also receive extended frames when in promiscuous mode.
* Change a if (...) panic() to a KASSERT().mux2004-05-241-2/+2
|
* A handler for ioctl(SIOCSIFCAP) should not alter a bit inyar2004-05-231-1/+2
| | | | | | | if_capenable unless the interface driver is actually able to toggle the respective capability on and off. Reviewed by: ru
* We don't need to initialize if_output, ether_ifattach() does itmux2004-05-231-1/+0
| | | | for us.
* Cosmetic:yar2004-05-211-2/+6
| | | | | Set capability bits in a consistent way. Add a comment on why the VLAN_MTU stuff comes after ether_ifattach().
* The driver fxp(4) has reception of large frames enabled hardcodedly,yar2004-05-211-0/+1
| | | | so let VLAN_MTU be marked in if_capenable from the beginning.
* Implemented per-interface polling(4) control.ru2004-04-111-1/+16
|
* Add new ID for Intel 82562ET (ICH5/ICH5R) Pro/100 VE Ethernet.imp2004-04-071-0/+1
| | | | | Submitted by: Stefan Bethke PR: 61320
* Convert callers to the new bus_alloc_resource_any(9) API.njl2004-03-171-5/+4
| | | | | Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
* Adjust $FreeBSD$'s.obrien2004-03-171-3/+0
|
* Announce ethernet MAC addresss in ether_ifattach().mdodd2004-03-141-3/+0
|
* Sometimes cardbus attachments don't attach, so while we track downimp2003-11-281-0/+1
| | | | | | | | this problem put these lines back in. While they should be unnecessary, they appear to be sometimes necessary. Reviewed in concept: dfr Approved by: re (scottl@)
* Remove explicit cardbus attachments from drivers where this is identicaldfr2003-11-031-1/+0
| | | | | | | to the pci attachment. Cardbus is a derived class of pci so all pci drivers are automatically available for matching against cardbus devices. Reviewed by: imp
* Replace the if_name and if_unit members of struct ifnet with new membersbrooks2003-10-311-2/+1
| | | | | | | | | | | | | if_xname, if_dname, and if_dunit. if_xname is the name of the interface and if_dname/unit are the driver name and instance. This change paves the way for interface renaming and enhanced pseudo device creation and configuration symantics. Approved By: re (in principle) Reviewed By: njl, imp Tested On: i386, amd64, sparc64 Obtained From: NetBSD (if_xname)
* Remove unused FXP_UNIT() macro.brooks2003-10-301-2/+0
|
* mark interrupt handlers MPSAFEsam2003-10-291-1/+1
|
* change timeout to be MPSAFEsam2003-09-052-5/+5
| | | | Sponsored by: FreeBSD Foundation
* Use PCIR_BAR(x) instead of PCIR_MAPS.jhb2003-09-021-2/+2
| | | | | Glanced over by: imp, gibbs Tested by: i386 LINT
* Use __FBSDID().obrien2003-08-241-0/+3
| | | | Also some minor style cleanups.
* Prefer new location of pci include files (which have only been in theimp2003-08-221-2/+2
| | | | | tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
* Use the revision ID from PCI configuration space to identify Inteljdp2003-08-041-23/+41
| | | | | | | 8255x chips more precisely. The information was obtained from Intel's Open Source Software Developer Manual for the 8255x. MFC after: 1 day
* Use the BUS_DMA_ZERO flag.mux2003-07-271-4/+2
|
* De-inline some functions. It doesn't gain us anything and bloatsmux2003-07-221-13/+13
| | | | | | code size by 3616 bytes. Furthemore, it was previously ignored by GCC. While I'm at it, fix some bogus comments.
* Unlock the fxp driver lock before calling fxp_poll() to avoid recursing onjhb2003-07-111-1/+1
| | | | | | | the lock when using DEVICE_POLLING. Tested by: Robin P. Blanchard <Robin.Blanchard@gactr.uga.edu> Reviewed by: njl
* All current uses of pci_set_powerstate are bogus, at least in theory.imp2003-07-031-4/+8
| | | | | | | | | | However, they are presently necessary due to bigger bogusness in the pci bus layer not doing the right thing on suspend/resume or on initial device probe. This is exactly the sort of thing that the BURN_BRIDGES option was invented for. Mark all of them as BURN_BRIDGES. As soon as I have the powerstate stuff properly integrated into the pci bus code, I intend to remove all these workarounds.
* Mega busdma API commit.scottl2003-07-011-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg. Lockfunc allows a driver to provide a function for managing its locking semantics while using busdma. At the moment, this is used for the asynchronous busdma_swi and callback mechanism. Two lockfunc implementations are provided: busdma_lock_mutex() performs standard mutex operations on the mutex that is specified from lockfuncarg. dftl_lock() is a panic implementation and is defaulted to when NULL, NULL are passed to bus_dma_tag_create(). The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred. Drivers that do not provide their own locking can pass busdma_lock_mutex,&Giant args in order to preserve the former behaviour. sparc64 and powerpc do not provide real busdma_swi functions, so this is largely a noop on those platforms. The busdma_swi on is64 is not properly locked yet, so warnings will be emitted on this platform when busdma callback deferrals happen. If anyone gets panics or warnings from dflt_lock() being called, please let me know right away. Reviewed by: tmm, gibbs
* Drop locks before calling if_input() since it may re-enter fxp_start()njl2003-06-231-0/+10
| | | | | | | | | in the netisr case. This would result in a lock reversal. This fixes the net.isr.enable=1 case. Better performance might be obtained by chaining all packets received, dropping the lock, and then calling if_input() on each one. Reported by: hmp
* Add a new device ID.mux2003-06-121-0/+1
| | | | Submitted by: Tom Alsberg <alsbergt@cs.huji.ac.il>
* Replace if_fxp's handrolled defrag function with m_defrag.silby2003-06-021-14/+3
| | | | | | No actual bug with the existing code, just tidying things up. Submitted by: hmp
* Always set the hardware parse bit in the IPCB structure when thistruckman2003-05-251-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | structure, which is new to the 82550 and 82551, is used to transmit a packet. This appears to fix the packet truncation problem that was observed when using 82550-based fxp cards to transmit ICMP or fragmented UDP packets of certain lengths which only had one to three bytes in the second and final mbuf of the packet. This matches a note in the "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer Manual", which says that the hardware parse bit should be set when sending these types of packets. There have also been unconfirmed reports of similar problems when transmitting TCP packets, which should not be affected by the above mentioned change because the hardware parse bit was already being set if the stack requested hardware checksumming of the packet. If the problem remains, the use of the IPCB structure can be disabled to cause the driver to fall back to using the older 82559 interface with 82550-based cards by setting hint.fxp.UNIT_NUMBER.ipcbxmit_disable to a non-zero value at boot time, or using kenv to set this variable before using kldload to load the fxp driver. Approved by: re (jhb)
* Add a tunable/sysctl "hw.fxp_noflow" which disables flow control supportrwatson2003-05-161-1/+5
| | | | | | | | | | | | | on if_fxp cards. When flow control is enabled, if the operating system doesn't acknowledge the packet buffer filling, the card will begin to generate ethernet quench packets, but appears to get into a feedback loop of some sort, hosing local switches. This is a temporary workaround for 5.1: the ability to configure flow control should probably be exposed by some or another management interface on ethernet link layer devices. Approved by: re (bmah) Reviewed by: mux
* GCC 3.3 complains about anonymous structures in unions, somux2003-05-141-7/+7
| | | | | | | give the fxp_ipcb structure a name in the fxp_rfa structure. Submitted by: peter Approved by: re (jhb)
* Fix the unaligned access problems that some people saw on alphamux2003-05-121-1/+1
| | | | | | | | | by using a __packed keyword for the fxp_rfa structure. The Intel guys who designed this structure with unaligned fields deserve to be shot. Tested by: kris Approved by: re@ (jhb)
* Fix tpyo in last commit.imp2003-04-301-1/+1
| | | | Noticed by: kuriyama-san
* Get rid of the redundant 'gone' field, and overload suspend instead.imp2003-04-302-13/+12
| | | | | | | | | | | | | | Check for suspend before the device polling, rather than after it. Check to see if the current thread owns the lock in ioctl and return EBUSY if it does. This advances the locking to the point that I can eject my fxp card 10 times in a row, but I agree with Jeff Hsu that we need to get the network layer locking finished before chasing more of the races here (actually, he doesn't think this set is worth it even). There's a number of races between FXP_LOCK in detach and all other users of FXP_LOCK, and this gets back to the 'device with sleepers being forcibly detached' problem as well...
* (5) from last commit was omitted by mistake:imp2003-04-291-0/+3
| | | | (5) Return immediately from fxp_intr() if gone is set.
* Fix 5 bugs:imp2003-04-292-8/+11
| | | | | | | | | | | 1) always call fxp_stop in fxp_detach. Since we don't read from the card, there's no need to carefully look at things with bus_child_present. 2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid a possible deadlock reported by jhb. 3) add gone to the softc. Set it to true in detach. 4) Return immediately if gone is true in fxp_ioctl 5) Return immediately if gone is true in fxp_intr
OpenPOWER on IntegriCloud