summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci/if_wpivar.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Stop exporting `wt_hwqueue' now that drivers don't advertise it.mpi2020-10-111-2/+1
| | | | Pointed by and ok jsg@
* Kill unused IEEE80211_RADIOTAP_HWQUEUE.mpi2020-10-091-3/+2
| | | | | | | | | | Its value is conflicting with an effort to standardize TX flags fields of the radiotap header from Mathy Vanhoef. This flag used to indicate the presence of a specific hardware queue used by WME but is unchecked. ok sthen@, kn@
* A pile of sizes to free(9). In test for a few days in snapshots.deraadt2017-04-081-1/+2
| | | | | Errors will result in nice clean panic messages so we know what's wrong. Reviewed by dhill visa natano jsg.
* convert busy flag and tsleep to rwlock as in iwmtedu2016-09-051-2/+2
|
* Seems we simply have tolibe with fatal firmware errors. Even Linux, with itskettenis2013-11-281-2/+3
| | | | | | | driver written by Intel engineers occasionally gets them. So when we get one, simply reset the chip, reload the firware and bring the interface up again. ok chris@, phessler@, mpi@
* replace workqs with tasks for handling resumedlg2013-11-141-2/+2
| | | | from kimberley manning
* remove the powerhook code. All architectures now use the ca_activate treederaadt2010-09-071-2/+1
| | | | | traversal code to suspend/resume ok oga kettenis blambert
* Add suspend/resume logic. As discussed with phessler@, incorporatingkettenis2010-07-221-1/+2
| | | | suggestions by damien@.
* Prevent a process from entering wpi_ioctl while another process iskettenis2010-07-221-1/+2
| | | | | | | tsleep'ing (for example waiting for the firmware to become alive) in iwn_init. ok damien@
* nuke the temperature sensor.damien2009-11-171-3/+1
| | | | | it is totally useless since (contrary to the one in iwn(4)) it is not in any known unit (can't be converted to degK or degC).
* switch wpi(4) and iwn(4) over to MCLGETI.damien2009-05-121-13/+2
| | | | | | | | | notice that i'm not using the per-ifp mbuf accounting/mitigation yet. for iwn(4), this means we wont' be able to support full 8KB AMSDU on machines without an IOMMU since >4KB clusters are not guaranteed to be physcontig. fortunately, we can program the hardware to do 4KB AMSDUs only. simplify {pwi,iwn}_dma_contig_alloc while i'm here: use BUS_DMA_ZERO
* allow users to select a fixed rate.damien2008-12-031-1/+3
|
* rework the rate coding code to get rid of the ugly {wpi,iwn}_plcp_signal()damien2008-11-091-1/+2
| | | | function. will be required for future MCS support in iwn.
* major wpi(4) overhaul.damien2008-11-081-6/+30
| | | | | | | | | wpi(4) and iwn(4) used to be in sync but with the latest iwn(4) changes, this was no longer the case. that commit repair this. it brings HW CCMP encryption/decryption among other things. requires an update of the wpi-firmware package. please report any regression you might see.
* all TX rings have the same fixed size (256 entries) and this is notdamien2007-11-191-3/+2
| | | | configurable so simplify rings allocation a bit.
* - add callbacks for setting EDCA parameters and pairwise crypto keys.damien2007-09-111-3/+2
| | | | - tweaks to make it look more like iwn(4).
* when running out of rx buffers, allocate a new mbuf and copy the rxdamien2007-08-221-2/+2
| | | | | | | | | | | | | | | buffer into it using m_copym2() instead of just dropping the received frame. otherwise, it may happen that all rx buffers are queued by tcp_input() waiting for a frame that will never arrive because we are dropping it. when it happens, rx stop working and it is hard to recover from this. the problem is not visible when using WEP because WEP decryption is currently done by software and that rx buffers are copied into mbufs by the software decryption code. while i'm here, increase the number of rx buffers allocated by wpi(4) from 80 to 96 to limit the number of copies. problem and solution found by bluhm@ - thanks.
* do not allocate ring descriptors for the service queue.damien2007-06-161-2/+1
| | | | | | | | this queue is used to load the firmware and the descriptors are written differently (in wpi_load_segment()). so the DMA descriptors were actually unused. saves 16KB of memory.
* Major wpi(4) update:damien2007-06-051-8/+30
| | | | | | | | | | | | | | | | | | 1/ Update the driver to use the new firmware images from Intel (2.14.3.) 2/ Read the list of supported channels from the EEPROM instead of having it hard-coded in the driver. 3/ Limit output power to what is specified in EEPROM. 4/ Decrease output power for highest OFDM rates to reduce distortion. 5/ Automatically adjust output power to temperature changes for increased throughput and range. 6/ Attach the adapter's onboard thermal sensor to the sensor framework. 7/ Replace 'magic' fields in structures with their correct definitions. NOTE1: you must upgrade your wpi-firmware package to rev 2.14.3 or the driver will stop working. NOTE2: if you are using a channel not allowed by the regulatory domain of your adapter, you will no longer be able to associate.
* make sure wpi_iter_func() is called at splnet.damien2006-10-231-1/+2
| | | | | simplify wpi_dma_contig_alloc(). various cosmetic tweaks while i'm here.
* Completely rework the allocation/management of Rx buffers.damien2006-08-281-2/+15
| | | | | | | | | | | The firmware expects 3KB Rx buffers so we can't just map mbuf clusters which are only 2KB. Also it seems that Rx buffers must be aligned on a 1KB boundary which is not necessary the case with mbuf clusters. We want to make damn sure the firmware will not DMA anything outside the mapped Rx buffers. The size of the Rx buffers is probably configurable but Intel will refuse to answer to any question regarding the programmation of the chipset, and a dump of the device registers led to nowhere.
* - improve scan code to support scanning of 802.11a channelsdamien2006-08-011-3/+3
| | | | | | - fix protection mode - fix association to APs hiding their SSID + various cosmetic tweaks while i'm here
* Move AMRR rate control algorithm out of wpi(4) and ural(4), into net80211.damien2006-06-171-8/+5
| | | | ok brad@
* automatic rate control (AMRR) + cosmetic and small fixesdamien2006-05-251-1/+12
|
* more radiotap.damien2006-05-201-2/+6
|
* more rx radiotap statsdamien2006-05-201-4/+12
|
* - fix short slot time and short preamble settingsdamien2006-05-201-3/+3
| | | | | | | - fix basic rates setting - fix check for WEP encryption (authreq frames might require encryption in shared mode) - cleanup a few things while i'm here
* mega-commit of unrelated changes:damien2006-05-171-10/+13
| | | | | | | | | | | | | | - factor out contiguous DMA allocations (the same code was duplicated in several places and was sometimes incorrect) - s/EIO/ETIMEDOUT where it makes sense - s/memset/bzero/g - don't always bzero the ring descriptors - scan channels 1-14 instead of 1-13 - remove the auhmode stuff since mgt frames are sent by net80211 - remove the SCANALL flag since the f/w notifies us when it switches to another channel - don't re-enable interrupts on f/w panics - KASSERT that commands fit in a descriptor
* Initial import of wpi(4), a blob-free driver for Intel PRO/Wireless 3945ABGdamien2006-05-141-0/+131
802.11 adapters as found in Centrino Duo laptops. More to come but works well enough for me to commit this over a wpi(4). go for it deraadt@