summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_xlreg.h
Commit message (Collapse)AuthorAgeFilesLines
* - Use the xl_stats_update() callout instead of if_slowtimo() formarius2006-12-061-0/+1
| | | | | | | | driving xl_watchdog() in order to avoid races accessing if_timer. While at it relax the watchdog a bit by reloading it in xl_txeof()/ xl_txeof_90xB() if there are still packets enqueued. - Use bus_get_dma_tag() so xl(4) works on platforms requiring it. - Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
* Whitespace nits.ru2006-09-151-1/+1
|
* Consistently use if_printf() only in interface methods: if_start,glebius2006-09-151-0/+1
| | | | | | | | | | if_ioctl, if_watchdog, etc, or in functions that are used by these methods only. In all other cases use device_printf(). This also fixes several panics, when if_printf() is called before softc->ifp was initialized. Submitted by: Alex Lyashkov <umka sevcity.net>
* Various fixups to locking:jhb2005-08-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | - Remove a lot of superfluous locking during attach. There is no need to lock access to the driver until some other thread has a way of getting to it. For ethernet drivers the other ways include registering an interrupt handler via bus_setup_intr(), calling ether_ifattach() to hook into the network stack, and kicking off a callout-driven timer via callout_reset(). - Use callout_* rather than timeout/untimeout. - Break out of xl_rxeof() if IFF_DRV_RUNNING is clear after ifp->if_input returns to handle the case where the interface was stopped while we were passing a packet up the stack. Don't call xl_rxeof() in xl_rxeof_task() unless IFF_DRV_RUNNING is set. With these fixes in place, any outstanding task will gracefully terminate as soon as it gets a chance to run after the interface has been stopped via xl_stop(). As a result, taskqueue_drain() is no longer required in xl_stop(). The task is still drained in detach() however to make sure that detach() can safely destroy the driver mutex at the end of the function. - Lock the driver lock in the ifmedia callouts and don't lock across ifmedia_ioctl() in xl_ioctl(). Note: glebius came up with most of (3) as well independently. I took a rather roundabout way of arriving at the same conclusion. MFC after: 3 days
* Stop embedding struct ifnet at the top of driver softcs. Instead thebrooks2005-06-101-1/+1
| | | | | | | | | | | | | | | | | | | | struct ifnet or the layer 2 common structure it was embedded in have been replaced with a struct ifnet pointer to be filled by a call to the new function, if_alloc(). The layer 2 common structure is also allocated via if_alloc() based on the interface type. It is hung off the new struct ifnet member, if_l2com. This change removes the size of these structures from the kernel ABI and will allow us to better manage them as interfaces come and go. Other changes of note: - Struct arpcom is no longer referenced in normal interface code. Instead the Ethernet address is accessed via the IFP2ENADDR() macro. To enforce this ac_enaddr has been renamed to _ac_enaddr. - The second argument to ether_ifattach is now always the mac address from driver private storage rather than sometimes being ac_enaddr. Reviewed by: sobomax, sam
* Calling xl_rxeof() at the end of xl_start_locked() leads to recursionglebius2005-05-201-0/+1
| | | | | | | | | in case of IP fast forwarding. Enqueue a taskqueue(9) task instead of calling xl_rxeof() directly. Reported & tested by: Slava Alpatov Reviewed by: wpaul MFC after: 1 week
* xl(4) meets polling(4). Hardware for this work kindly provided byru2005-03-261-0/+3
| | | | | | Eric Masson. MFC after: 3 weeks
* /* -> /*- for license, minor formatting changesimp2005-01-071-1/+1
|
* Add PCI and device ID's to if_xl to support:rwatson2005-01-031-0/+1
| | | | | | | | | | | 3C920B-EMB-WNM Integrated Fast Ethernet Controller Submitter reports that the card appears to autonegotiate properly, and operate well with high levels of NFS traffic. PR: 75253 Submitted by: "Oleg V. Nauman" <oleg at reis dot zp dot ua> MFC after: 2 weeks
* Actually turn on driver locking in xl(4).bms2004-07-091-10/+0
|
* Fix whitespace and comments.bms2004-07-041-20/+25
|
* Drop the driver lock around calls to if_input to avoid a LOR whensam2003-11-141-0/+2
| | | | | | | | the packets are immediately returned for sending (e.g. when bridging or packet forwarding). There are more efficient ways to do this but for now use the least intrusive approach. Reviewed by: imp, rwatson
* - Avoid calling pci_get_device() more than once in a single function.mdodd2003-09-141-0/+1
| | | | | - Provide a mechanism to prevent the use of MMIO. - Prevent the use of MMIO for all 3c575 cardbus cards.
* Support for large frames for VLANs was added by tweaking the packet sizewpaul2003-07-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | register, present only on 3c90xB and later NICs. This meant that you could not use a 1500 byte MTU with VLANs on original 3c905/3c900 cards (boomerang chipset). The boomerang chip does support large frames though, just not in the same way: you can set the 'allow large frames' bit in the MAC control register to receive frames up to 4K in size. Changes: - Set the 'allow large frames' bit for boomerang chips and increase the packet size register for cyclone and later chips. This allows us to use IFCAP_VLAN_MTU on all supported xl(4) NICs. - Actually set the IFCAP_VLAN_MTU flag in the capabilities word in xl_attach(). - Change the method used to detect older boomerang chips. My 3c575C cardbus NIC was being incorrectly identified as 3c90x chip instead of 3c90xB because the capabilities word in its EEPROM reports a bizzare value. In addition to checking for the supportsNoTxLength bit, also check for the absence of the supportsLargePackets bit. Both of these cases denote a 3c90xB chip. - Make RX and TX checksums configurable via the SIOCSIFCAP ioctl. - Avoid an unecessary le32toh() in xl_rxeof(): we already have the received frame size in the lower 16 bits of rxstat, no need to read it again. Tested with 3c905-TX, 3c900-TPO, 3c980C and 3c575C NICs.
* Instead of relying on a compile time define to determine whether the xlsilby2003-03-181-0/+1
| | | | | | | | | driver should use port or memory based IO, determine it dynamically at runtime, preferring MMIO where possible. This helps us support newer arches which dislike port based access better. Tested on i386 & sparc64, with 3c900, 905, 905b, and 905C cards. (in varying combinations by both jake and myself)
* - Fix mbuf leak when we successfully allocate a new mbuf but fail tomux2003-02-181-0/+1
| | | | | | | | | bus_dmamap_load() it. - Make it so reusing mbufs when we can't allocate (or map) new ones actually works. We were previously trying to reuse a mbuf which was already bus_dmamap_unload()'ed. Reviewed by: silby
* Correctly identify the 3C920B chipset; although it may ship with some Nforce2silby2003-01-221-1/+1
| | | | | | boards, it's definitely not an Nvidia chip. Info from: Nvidia's Linux Network driver & pciids.sourceforge.net
* Make the xl driver work on sparc64:tmm2003-01-191-0/+1
| | | | | | | | | | | | | | | | - Add conversions to/from little endian for fields that the NIC accesses by DMA as required. - Add some bus_dmamap_sync() calls, and correct some existing ones. - Read the receiver information from the EEPROM in an endian-neutral manner. - Load all RX and TX descriptors in a single DMA map up front, and get the bus addresses of individual descriptors by address arithmetic; this fixes multiple use of the descriptor tags, which would have undesired effects. It seems that xl still does not work on e250 boxen, for reasons which are not clear yet. Reviewed by: mux
* Partial support for the nVidia nForce2 chipset's on-board Broadcom/Altima PHYobrien2003-01-121-0/+1
| | | | | | | and 3com MAC. Specifications for the Altima PHY are available at: http://www.altimacom.com/products/ac101L.html Submitted by: Mikko S. Hyvarinen <morphy@morphy.iki.fi>
* Add support for the 3c555 miniPCI chipset.silby2003-01-061-0/+1
| | | | | | Submitted by: johannes <johannes@paradise.net.nz> PR: 46603 MFC after: 3 days
* Convert the xl(4) driver to the busdma API. This should makemux2002-12-171-18/+21
| | | | | | | it possible to use this driver under ia64, sparc64 (though there may be endianness issues with this one) and other archs. Tested on: i386, alpha (gallatin)
* Add some magic bits necessary to turn the transmitter on for somesilby2002-10-221-0/+3
| | | | | | | | | (newer) 556B chips. Requested & tested by: Dinesh Nambisan <dinesh@nambisan.net> Magic bits found by: Dave Dribin & Donald Becker MFC After: 3 days
* Turn off the premature locking in xl. The driver tries to use the mutexespeter2002-10-141-0/+6
| | | | | | as spl replacements, but you cant sleep while holding mutexes. This change has been made on many other drivers.
* Fix a problem where stats overflow interrupts would causesilby2001-12-171-1/+1
| | | | | | | | | | a major slowdown, and re-enable stats overflow interrupts. For future reference, the bug was in our code, and not some bug in the 3com chips. Reviewed by: wpaul MFC after: 2 days
* Add support for the 3c656B cardbus adapter. This is one half of awpaul2001-08-281-1/+3
| | | | | | | | | | | dual function card. It needs pretty much the same flags as the 656C, except that it seems to need both the INVERT_MII_PWR and INVERT_LED_PWR flags set. Tested with cardbus in -current as of today. Also added support for the 3c656, which looks to be the same as the 656B, except it doesn't need the EEPROM_8BIT flag. I think. This one is untested, but the added support should not break any of the other cards.
* Close PR #27742: allow the xl driver to receive VLAN tagged frames bywpaul2001-05-311-1/+2
| | | | | | | | | | | | | | | setting the 'max packet size' register in window 3. This only works for cards based on the cyclone or newer chipsets (i.e. it won't work with the original 3c905/boomerang cards). There is a trick which will work with the boomerang, which is to turn on the 'large packets ok' bit in the MAC control register, however this lets the chip accept any frame up to 4K in length, which is larger than the mbuf cluster buffers we use to receive frames. If somebody sends us such a frame and the chip DMAs it to us, it could write past the end of the cluster buffer and clobber something. PR: kern/27742
* Disable the 'stats counter overflow' interrupts since they can happenwpaul2001-05-111-1/+1
| | | | | | much more often that expected and negatively impact performance when running at 100mbps. I need to figure out if there's a better way to handle this, but for now this shouldn't hurt anything.
* Change and clean the mutex lock interface.bmilekic2001-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mtx_enter(lock, type) becomes: mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks) mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized) similarily, for releasing a lock, we now have: mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN. We change the caller interface for the two different types of locks because the semantics are entirely different for each case, and this makes it explicitly clear and, at the same time, it rids us of the extra `type' argument. The enter->lock and exit->unlock change has been made with the idea that we're "locking data" and not "entering locked code" in mind. Further, remove all additional "flags" previously passed to the lock acquire/release routines with the exception of two: MTX_QUIET and MTX_NOSWITCH The functionality of these flags is preserved and they can be passed to the lock/unlock routines by calling the corresponding wrappers: mtx_{lock, unlock}_flags(lock, flag(s)) and mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN locks, respectively. Re-inline some lock acq/rel code; in the sleep lock case, we only inline the _obtain_lock()s in order to ensure that the inlined code fits into a cache line. In the spin lock case, we inline recursion and actually only perform a function call if we need to spin. This change has been made with the idea that we generally tend to avoid spin locks and that also the spin locks that we do have and are heavily used (i.e. sched_lock) do recurse, and therefore in an effort to reduce function call overhead for some architectures (such as alpha), we inline recursion for this case. Create a new malloc type for the witness code and retire from using the M_DEV type. The new type is called M_WITNESS and is only declared if WITNESS is enabled. Begin cleaning up some machdep/mutex.h code - specifically updated the "optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently need those. Finally, caught up to the interface changes in all sys code. Contributors: jake, jhb, jasone (in no particular order)
* Add device ID for the 3c565C card. I followed exactly the 3c575c, butimp2000-12-011-0/+1
| | | | | further tweaks may be necessary down the road. This does nothing with the serial side of the card.
* add support for 3Com 3c575TX Fast Etherlink XL.sanpei2000-11-021-0/+1
| | | | | | | Device information for 3C575-TX is from NetBSD, sys/dev/cardbus/if_ex_cardbus.c file. Reviewed by: wpaul, imp
* Add support for cardbus card's chips. This will make the 3c575 cardsimp2000-10-161-0/+8
| | | | | | work once the rest of the cardbus infrastructure has been committed. Submitted by: Jonathan Chen <jon@spook.org>
* First round of converting network drivers from spls to mutexes. Thiswpaul2000-10-131-0/+4
| | | | | | | | takes care of all the 10/100 and gigE PCI drivers that I've done. Next will be the wireless drivers, then the USB ones. I may pick up some stragglers along the way. I'm sort of playing this by ear: if anyone spots any places where I've screwed up horribly, please let me know.
* Add support for the 3Com 556 and 556B mini-pci adapters used on somewpaul2000-08-281-0/+13
| | | | | | | laptops. I've checked that this still works with the other cards and it works with the 3c556 that I have access to, but I want to check that it works with the 556B mentioned in PR #20878 before I close out the PR and merge to -stable.
* Update the xl driver to recognize yet another 3c905B/3c905C class NIC:wpaul1999-12-161-0/+1
| | | | | | | | | | | | | | | | | the 3c450-TX HomeConnect. Like the 3cSOHO100-TX OfficeConnect, this NIC uses the same ASIC as the 3c905B/3c905C but is targeted for a particular market segment (home users). It is somewhat less expensive than the 3c905B/3c905C ($49, according to the 3Com web site), comes with its own custom driver kit and is bundled with various goofy Windows software packages designed to demonstrate the niftyness of home networking (networked game demos, etc...). Changes are: - Add PCI ID to list in if_xlreg.h. - Update xl_devs table in if_xl.c. - Update xl_choose_xcvr() to consider the HomeConnect the same as all the other 10baseT/100baseTX cards.
* Make some small tweaks:wpaul1999-10-141-0/+1
| | | | | | | | | | | | - When setting/clearing promisc mode, just update the filter, don't reset the whole interface. - Call xl_init() in xl_ifmedia_upd() when setting miibus media modes. This fixes a problem with the 3c905B-COMBO where switching from 10base5/AUI or 10base2/BNC to a 10/100 mode doesn't always work right. - Attempt to reset the interface in xl_init() so that we know we're getting the receive and transmit rings reset properly.
* Add an alternate transmit strategy for 3c90xB adapters based on the transmitwpaul1999-09-201-2/+17
| | | | | | | | | | | | | | | strategy used in the 3Com Linux driver. The new strategy is to use transmit descriptor polling -- that is, the NIC polls the descriptors to see when new packets are available for transmission. The advantage to the new scheme is that no register accesses are needed in the transmit routine. The old scheme requires several register accesses to stall the TX engine, update the TX DMA list pointer register, then unstall the TX engine. Hopefully the new scheme will provide improved transmit performance with less CPU overhead. This only affects the 3c90xB or 3c90xC cards, not the 3c90x cards. This means the original 3c900 and 3c905 cards are unaffected. Newer cards include the 3c900B series, the 3c905B, 3c980, 3c980B, 3c905C and 3c905C, and the 3cSOHO100-TX OfficeConnect.
* 3Com has produced their own Linux driver for the 3c90x/3c90xB series cards.wpaul1999-09-151-0/+1
| | | | | | | | It's GPL'ed of course, but looking over it tonight I learned of Yet Another Fast EtherLink XL Adapter: the 3c980C server adapter. This is basically an updated version of the 3c980 that uses the Tornado ASIC instead of the earlier Hurricane ASIC. The only change here is to add the new PCI device ID (0x9805) and corresponding table entries.
* Convert the 3Com XL driver to miibus. This one is a little trickywpaul1999-08-291-154/+1
| | | | | | | | | | | | | | | | due to the fact that there are non-MII cards supported by the same driver and I don't have all of the cards available for testing. There's also the 3c905B-COMBO which has MII, AUI and BNC media ports all in one package. Supporting the COMBO is difficult because we have to add the 10base5 and 10base2 media types to the same ifmedia struct as the MII-attached types, however there is no way to force the miibus and child PHYs into existence before xl_attach() completes, so there is no ifmedia struct available in xl_attach(). What we do inistead is use the mediainit method as a callback: when a child PHY is attached, it calls the miibus mediainit routine which selects a default media. This routing also calls the NIC driver's mediainit method (if it implements one) at which point we can safely add the other media types.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Convert the xl driver to newbus. It is now possible to make this driverwpaul1999-07-201-1/+4
| | | | | | | | | | into a loadable module, and all of the platform dependencies are gone (except for the alpha_XXX_dmamap() thing, which is another issue -- I still don't know how to use the busdma stuff with a network driver). Also increase the delay in xl_reset(); testing on a 486/66 with a 3c905C shows that reading the EEPROM fails immediately after a reset. Waiting a little longer after the reset completes seems to fix it.
* Head for the hills friends and neighbors, 3Com has yet another 3c90Xwpaul1999-05-301-1/+2
| | | | | | | | chipset. First you thrilled to the 3c905, then you trembled at the 3c905B, now gaze in wonder at: the 3c905C! This appears to be another 3c90X series chip called the Tornado (PCI ID 0x10B7/0x9200) and should be equivalent (from the driver API perspective) to the 3c905B, so all we have to do is add the PCI ID to the list.
* Allow chipset drivers to specify the direct-mapped DMA window's mask ingallatin1999-05-261-3/+3
| | | | | | | | | | preparation for tsunami support. Previous chipsets' direct-mapped DMA mask was always 1024*1024*1024. The Tsunami chipset needs it to be 2*1024*1024*1024 These changes should not affect the i386 port Reviewed by: Doug Rabson <dfr@nlsystems.com>
* Dynamically increase TX start threshold if TX underruns are detected.wpaul1999-05-051-1/+2
|
* Bunch of updates:wpaul1999-04-301-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Try to unbreak what I broke by screwing with the tx queuing again. I'm waiting for a few more people to test out this code and report back before I move it into current. Hopefully it will be soon. Basically I reverted to the old TX queuing strategy. - Add experimental support for the 3c900B-FL (10mbps ST fiber). The card should be detected properly and the 10baseFL mode supported, but again I'm still waiting for word from a tester to see if this actually works. It shouldn't affect the other cards though; all the differences are in media selection. - Set the TX start threshold register to get better performance. - Increase the size of the RX and TX rings. UDP performance was pretty bad because the TX ring was too small. Should be substantially better now (I can saturate the link with either TCP or UDP now). - Change some of the #defines to reflect proper 3Com ASIC names (boomerang, cyclone, krakatoa, hurricane). - Simplify and reorganize interrupt handler; ack all interrupts right away and then process them. This avoids a potential race condition. (Noted by Matt Dillon.) - Reorganize the bridging code to eliminate using a goto to jump into the middle of an if() {} clause. Sorry, that just made my brain itch. - Use m_adj() in xl_rxeof(). - Make the payload alignment in xl_newbuf() the default (instead of just conditionally defined for the alpha) to improve NFS performance (avoids need for nfs_realign()).
* - Close PR #11136: add PCI ID for another new cyclone device: thewpaul1999-04-151-1/+4
| | | | | | | | | | | | 3c900B-TPC (twisted pair and coax). Treated similarly to the 3c900B-COMBO, except no AUI port. - Fix media selection so that it's possible to select the AUI and BNC ports on the 3c905B-COMBO. This board is now fully supported. - Change TX queueing strategy to hopefully be more efficient by avoiding register accesses in xl_start(). Should provide small performance improvement and a little better reliability.
* Add support for the 3cSOHO100-TX, which is a "hurricane" chipsetwpaul1999-04-121-1/+2
| | | | | | (cut-down version of the "cyclone" for the small office/home office "cheap bastard" market). Basically the same as a 3c905B but without Wake-on-LAN, ROM socket, etc...
* Some small updates:wpaul1999-04-111-1/+2
| | | | | | | | | | | | | | | | - Wait longer for the reset to complete in xl_attach() to try and avoid 'command never completed' warnings. - Clean up a few odds and ends in xl_attach(). - Add PCI ID for the 3c905B-COMBO (a new card). Right now this is treated as a 3c905B; I need to dig up one of these cards for testing before I can make the AUI and BNC ports work. - Add a hack to force reading the I/O address directly from the PCI registers if pci_map_port() fails. I SHOULD NOT HAVE TO DO THIS: SOMEBODY WITH MORE PCI CLUES THAN I SHOULD INVESTIGATE WHY THIS HAPPENS.
* Make the xl and pn drivers work on FreeBSD/alpha and add them towpaul1999-03-271-31/+19
| | | | | | | | | | | | | | | sys/alpha/conf/GENERIC. Note: the PNIC ignores the lower few bits of the RX buffer DMA address, which means we have to add yet another kludge to make it happy. Since we can't offset the packet data, we copy the first few bytes of the received data into a separate mbuf with proper alignment. This puts the IP header where it needs to be to prevent unaligned accesses. Also modified the PNIC driver to use a non-interrupt driven TX strategy. This improves performance somewhat on x86/SMP systems where interrupt delivery doesn't seem to be as fast with an SMP kernel as with a UP kernel.
* Close PR #8384:wpaul1998-10-221-2/+2
| | | | | | | | | | | | Revert the transmission packet queueing strategy changes. Clearly I missed something while debugging this, although I never encountered any problems on my test machines. Also make one other minor change: jack up the TX reclaim threshold for 3c90xB adapters in order to stave off 'transmission error: 82' errors. Document the existence of the tx reclaim register (for inspecting the current reclaim threshold) in register window 5 (if_xlreg.h).
* Modify the transmit packet queuing strategy a bit to be a little lesswpaul1998-10-191-1/+2
| | | | | | | | | | | | | | agressive. With the old code, if a descriptor chain was already on its way to the chip, xl_start() would try to splice new chains onto the end of the current chain by stopping the transmitter, modifying the tail pointer of the current chain to point to the head of the new chain, then restart the transmitter. The manual says you're allowed to do this and it works, but I'm not too keen on it anymore. The new code waits until the eixsting chain has been sent and then queues the next waiting chain in the 'transmit ok' handler. Performance still looks good one way or the other.
OpenPOWER on IntegriCloud