| Age | Commit message (Collapse) | Author |
|---|
|
drivers update hardware configuration accordingly.
tested by myself, tb@, deraadt@, abieber@
ok mpi@
|
|
ok deraadt@
|
|
ok kettenis@
|
|
tell the firmware to always try the first rate in the table first.
ok kettenis@
|
|
in bsd.rd, and might uncover some bugs. Suggested by tedu@ and deraadt@.
ok sthen@ jasper@ deraadt@
|
|
Adds support for HT MCS 0-7 (theoretical limit 65 Mbit/s) and the
reception of A-MSDU and A-MPDU aggregated frames.
None of the optional 11n features are supported for now.
MIMO, 40Mhz channels, short guard interval, etc. are left for future work.
And we're not sending A-MSDU or A-MPDU frames yet either.
Tested with various 11a/b/g/n access points. With some APs I'm seeing
a noticable increase in throughput, especially on 5Ghz.
Also, fix automatic rate selection by using the current Tx rate selected
by AMRR as the upper bound for the firmware's rate table and updating the
firmware's table whenever AMRR switches Tx rate, rather than setting the
table just once after association and ignoring AMRR updates.
ok mpi@ krw@ (earlier version), ok jasper@
|
|
similar to config_defer(9).
ok mikeb@, deraadt@
|
|
prevent it from moving off-channel during association. The firmware issues
interrupts at beginning and end of the time event. The driver tried detecting
the beginning with a tsleep() in the newstate task followed by a wakeup()
from the interrupt handler. However, sometimes the newstate task did not get
scheduled until the time event had already passed, and association was aborted.
In rare cases the newstate task would even sleep forever and the iwm(4)
interface would stop working until reboot.
Fix these issues by issuing the time event and continuing association without
checking for a "go" from the firmware. Our kernel does not provide the
scheduling guarantees required for such precise synchronization so
association is more likely to fail with the additional check than without.
ok mpi@ tedu@
|
|
there are two things shared between the network stack and drivers
in the send path: the send queue and the IFF_OACTIVE flag. the send
queue is now protected by a mutex. this diff makes the oactive
functionality mpsafe too.
IFF_OACTIVE is part of if_flags. there are two problems with that.
firstly, if_flags is a short and we dont have any MI atomic operations
to manipulate a short. secondly, while we could make the IFF_OACTIVE
operates mpsafe, all changes to other flags would have to be made
safe at the same time, otherwise a read-modify-write cycle on their
updates could clobber the oactive change.
instead, this moves the oactive mark into struct ifqueue and provides
an API for changing it. there's ifq_set_oactive, ifq_clr_oactive,
and ifq_is_oactive. these are modelled on ifsq_set_oactive,
ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd.
this diff includes changes to all the drivers manipulating IFF_OACTIVE
to now use the ifsq_{set,clr_is}_oactive API too.
ok kettenis@ mpi@ jmatthew@ deraadt@
|
|
|
|
You never need <netinet/ip_var.h> nor <netinet/in_systm.h>.
|
|
This header is only needed because <netinet/if_ether.h> declares a
structure that needs it. But it turns out that <net/if.h> already
includes it as workaround.
A proper solution would be to stop declarting "struct ether_arp"
there. But no driver should need this header.
|
|
|
|
the specific queues are ic_mgtq, ic_pwrsaveq, and ni_savedq. rtw
had its own queue for beacons.
tested by mpi@ and jmc@
ok mpi@
|
|
|
|
ok stsp@
|
|
ok mpi@
|
|
iwm_mvm_scan_request() and always call ieee80211_end_scan() when done.
ok mpi@
|
|
|
|
Fixes occasional firmware errors while bringing the interface up or scanning.
ok phessler@
|
|
potential crash. This must have somehow been working by magic.
Fruther cleanup of QoS support in this driver is very much needed.
ok mpi@
|
|
ok phessler
|
|
ok phessler mpi zhuk
|
|
ok mpi@
|
|
at a time. The newstate task now always transitions to the most
recently requested state, rather than hopping along with every request.
This allows us get rid of the silly newstate generation counter, and
we can now task_del() a pending transition when the interface goes down.
While several issues with this driver remain, I believe this change
does not introduce new problems.
Tested by myself, jasper@, and zhuk@
|
|
The bsd.rd problems happened because of the net80211 detach/attach hack
which ran when the firmware is loaded for the first time.
Do the minimum of what needs to be done instead.
To fix lladdr random pick up a changing MAC address in the ioctl handler
and don't overwrite a custom MAC address while loading the firmware.
ok kettenis@
|
|
Noted by Adrian Chadd (FreeBSD).
ok kettenis@
|
|
|
|
Found by Matthew Dillon (Dragonfly). DMA sync hint from tedu@, ok mpi@
|
|
the firmware, rather than zeros. Matches what Linux iwlwifi does.
Spotted by Adrian Chadd (FreeBSD).
ok mpi@
|
|
debugging easier when it happens, as observed by matthieu@ (not reproducible
on demand, unfortunately).
ok mpi@
|
|
Linux is a moving target so these comments provide little value.
Discussed with kettenis and deraadt.
|
|
The bad news: Many laptops sold with iwm(4) cards don't have a wifi LED :-(
The good news: Laptops with LEDs and no wifi device white-list in BIOS
actually exist! Tested in one such machine.
ok kettenis@ deraadt@
|
|
recovery after device timeout a chance. Don't mess with the IFF_UP flag
in the watchdog since this isn't done anywhere except intel wifi drivers
which probably copied this pattern amongst each other.
ok kettenis@
|
|
|
|
IWM_NUM_OF_TBS - 2. We have IWM_NUM_OF_TBS slots, but use two of those
for sending commands to the firmware. Hopefully fixes the
iwm0: hardware error, stopping device
errors I've seen somewhat regularly.
ok claudio@, deraadt@
|
|
ok jca@
|
|
and scanning conditional on the 5GHz support bit in the nvm.
Problem reported and fix tested by Mattieu Baptiste.
ok stsp@ kettenis@
|
|
|
|
ok stsp@ kettenis@
|
|
data frames and fixed rates weren't really fixed and were converted into
the wrong hardware rate.
ok jsg@, deraadt@
|
|
ok kettenis@ deraadt@
|
|
Linux does.
ok jsg@
|
|
ok stsp@
|
|
ok kettenis@ stsp@ phessler@
|
|
OFDM frames conditional on the node via IEEE80211_F_USEPROT.
ok kettenis@
|
|
dc271ee0d04d12d6bfabacbec803289a7072fbd9 as it is known
to cause problems.
ok kettenis@
|
|
to -1. The result of this is tx frames were always sent out at fixed
rate 0 instead of ni_txrate.
Match the iwn behaviour and test ic_fixed_rate for -1 instead.
Problem spotted by kettenis@ in an earlier diff.
ok kettenis@ stsp@
|
|
ok kettenis@
|
|
ok stsp@ phessler@
|
