| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Pointed by and ok jsg@
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
| |
Errors will result in nice clean panic messages so we know what's wrong.
Reviewed by dhill visa natano jsg.
|
| |
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
from kimberley manning
|
|
|
|
|
| |
traversal code to suspend/resume
ok oga kettenis blambert
|
|
|
|
| |
suggestions by damien@.
|
|
|
|
|
|
|
| |
tsleep'ing (for example waiting for the firmware to become alive)
in iwn_init.
ok damien@
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
function. will be required for future MCS support in iwn.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
configurable so simplify rings allocation a bit.
|
|
|
|
| |
- tweaks to make it look more like iwn(4).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
simplify wpi_dma_contig_alloc().
various cosmetic tweaks while i'm here.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
- fix protection mode
- fix association to APs hiding their SSID
+ various cosmetic tweaks while i'm here
|
|
|
|
| |
ok brad@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
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@
|