MFC r344990:
Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.

- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.

MFC r343815:
iwn(4): plug initialization path vs interrupt handler races

There are few places in interrupt handler where the driver
lock is dropped; ensure that device is still running before
processing remaining ring entries.

PR: 192641

MFC r343235:
iwn(4): drop return code from iwn_*attach functions (they cannot fail)

While here, add missing trace 'end' marker in iwn5000_attach().

MFC r335785, r335812

r335785 by eadler:
iwn: Correct Centrino Advanced-N 6235 constants

The iwn 6235 is a 2x2 device (see
https://ark.intel.com/products/66890/Intel-Centrino-Advanced-N-6235-Dual-Band)

r335812 by eadler:
iwn: Add the missing IWN_SDID_6035_5 subdevice

MFC r314287:
iwn: stop all watchdogs on device shutdown.

Tested with Intel 6205, STA mode.

MFC r309822, r310375

r309822:
[iwn] Perform BUS_DMASYNC_PREREAD when initializing RX buffer

BUS_DMASYNC_PREREAD is required when setting up RX buffer, otherwise
data provided by card can be overwritten by data evicted from cache

Also use proper tag when setting up RX descriptor

Reviewed by: adrian, avos, ivadasz
Differential Revision: https://reviews.freebsd.org/D8717

r310375:
[iwn] Several fixes for DMA part of iwn(4)

- Perform DMS sync when accessing/initializing ICT table
- Fix some DMA sync operations to use matching tags

Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D8804

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

iwn: add watchdog for scanning.

Restart device if scanning was not done in time.

Tested by: david@catwhisker.org

PR: 209198
Differential Revision: https://reviews.freebsd.org/D6176

iwn: fix comments for iwn_read_eeprom_channels().

It's used for all channels (20MHz and 40MHz).

iwn: fix device reset after watchdog timeout.

Simple device reset (stop/start) is not enough here;
post-init state changes must be applied too.

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

iwn: do not buffer frames for non-passive channels (it's not needed).

iwn: switch to ieee80211_add_channel*()

Switch to add_channel / add_channel_ht40 + pass channel's TX power
for the last.

Tested by: dhw
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6141

sys: Make use of our rounddown() macro when sys/param.h is available.

No functional change.

[iwn] Don't try to seamlessly recover from a firmware panic; just restart
the interface.

I know this may be unpopular, but iwn is not yet completely ready for
a transparent firmware restart. I have this thing panic my laptop
reliably because 11n state isn't kept in sync and the TX completion
path ends up trying to free a null node reference.

wpi, iwn: fix check in find_eeprom_channel()

Return correct eeprom_chan structure pointer for 7, 8, 11 and 12 5Ghz
channels.

Remove bogus cast.

wpi, iwn: implement ic_getradiocaps method

This will allow to restore channel list after switching interface
to more restrictive regdomain.

Tested with Intel 3945BG (wpi) only.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4863

iwn: reduce code duplication in iwn_read_firmware()

- Separate 'firmware_put(sc->fw_fp, FIRMWARE_UNLOAD); sc->fw_fp = NULL;'
into iwn_unload_firmware().
- Move error handling to the end of iwn_read_firmware().

No functional changes.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4768

iwn(4): various simple fixes

- Fix mbuf leaks in iwn_raw_xmit() and iwn_xmit_task()
(regression since r288178).
- Check IWN_FLAG_RUNNING flag under lock.
- Remove m->m_pkthdr.rcvif initialization (fixed in r283994).
- Enclose some values in return statements into parentheses.

Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D4069

Remove BUS_DMA_NOWAIT from bus_dma_tag_create() invocations as it's
no valid flag there.

Switch PCI register reads from using magic numbers to using the names
defined in pcireg.h

net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ieee80211_raw_output().

This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774

net80211: free node reference in the ieee80211_parent_xmitpkt() when error happened.

Move error handling into ieee80211_parent_xmitpkt() instead of spreading it
between functions.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3772

Fix locking after my EDCA update change.

The net80211 lock is no longer held during this call, so we don't have
to unlock/relock.

Noticed by: David Wolfskill

Fix up error path handling after the recent churn.

* Don't free the mbuf in the tx path - it uses the transmit path now,
so the caller frees the mbuf.
* Don't decrement the node ref upon error - that's up to the caller to
do as well.

Tested:

* Intel 5300 3x3 wifi, station mode

Noticed by: <s3erios@gmail.com>

net80211 & wireless drivers: remove duplicate defines (noop)

* IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh).
* N(a) -> nitems(a).
* Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead).
* <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop).
* Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions.

Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3705

Remove the software queue, which is a remnant of ifnet ifqueue.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Remove now unneeded includes.

Migrate the stats API for iwn(4) into a cdev ioctl, rather than tying
into the vap.

This allows for possible hardware interaction without needing a vap
configured.

Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Migrate ifp->if_softc -> ic->ic_softc.

Tested:

* Lenovo T400 (Intel 5300)
* make universe

Revert the wifi ifnet changes until things are more baked and tested.

* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.

Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix

Attempt to make 5GHz HT/40 work on the 6xxx series NICs.

The 6205 (Taylor Peak) in the Lenovo X230 works fine in 5GHz 11a and 11n HT20,
but not 11n HT40. The NIC goes RX deaf the moment HT40 is configured.
It's so RX deaf that it doesn't even hear beacons and the firmware sends
"BEACON MISS" events. That's pretty deaf.

I tried configuring up the HT40 flags in monitor mode and it worked - so
I assumed that doing the transition from 20 -> 40MHz channel configuration
when going auth->assoc (ie, after the NIC has been partially configured)
is a problem.

So for now, let's just always set them if they're available.

Tested:

* Intel 5300, STA mode, 5GHz HT/40 AP; 2GHz HT/20 AP
* Intel 6205, STA mode, 5GHz HT/40, HT20, 11a AP; 2GHz HT/20 AP

This was pointed out to me by coworkers trying to use FreeBSD-HEAD
in the office on their Thinkpad T420p laptops.

TODO:

* I don't like how the HT40 flags are configured - the whole interop/
protection config should be re-checked. Notably, I think curhtprotmode
is 0 in a lot of cases, which means "no interoperability" and i think
that's busted.

Sponsored by: Norse Corp, Inc.

First cut at attempting to buffer frames until we see a beacon.

The iwn(4) firmware forgets most of its channel state after an RXON
command. This means that any beacons its seen on passive 5GHz channels
are forgotten upon an association/authorisation request.
This unfortuantely means that 5GHz association almost always fails -
the assoc and/or auth frames are dropped with a status of "passive
channel, haven't seen a beacon yet." (0x90.)

So:

* add an xmit queue, global, to buffer frames
* modify the xmit path to use the mbuf tag from net80211
to specify raw frame details
* buffer xmit frames from both raw and non-raw paths
* if a beacon is seen in the RX path, schedule a taskqueue to
send said frames and un-buffer things.
* flush frames during state change back to INIT, or NIC
down/up/detach.

This isn't the final shape I'd like this to be in but it certainly
is better than 5GHz "not working at all".

Tested:

* Intel 5100, STA mode (before spilling coffee)
* Intel 5300, STA mode (after spilling coffee)

Story:

* This has been bugging me at work for months, which I just
worked around by throwing an ath(4) into my Lenovo T400 cardbus
slot.

* Our ops director discovered indeed FreeBSD runs well on the
Lenovo T420p, except for that pesky 5GHz thing. So now developers
also can have a T420p running FreeBSD to do work with.
Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked."

* .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4)
NIC to put in a laptop - and I snapped.

Thus, the reason this is actually work related.

MFC after: 2 weeks
Sponsored by: Norse Corp, Inc.

Disable bgscan for now - it interferes with 11n activity and general
stability.

I'll re-enable it once the scan overhaul is done - the NIC itself
can do bgscan, but not how we're doing it.

MFC after: 2 weeks
Sponsored by: Norse Corp, Inc.

Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Use ic_printf() instead of if_printf().

Store softc in ic_softc and access it without using struct ifnet.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Various iwn(4) fixes.

* simplify channel logic for determining RF gain setting in scan setup
* don't set TX timer on error
* free node references for unsent frames on device stop
* set maxfrags to IWN_MAX_SCATTER-1 (first segment is used by TX command)
* add missing IWN_UNLOCK() from interrupt path when the hardware
disappears.
* pass control frames to host
* nitems() instead of local macro

Tested:

* Intel 5100, STA mode

PR: kern/196264
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>

iwn, wlan: fix typos
Fxi tow typos

Obtained from: DragonFlyBSD
MFC after: 3 days

Remove a private copy of ieee80211_add_ssid().

PR: kern/196116
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>

Mechanically convert to if_inc_counter().

Implement htprotmode handling.

This is separate to 11g protection - the default is to RTS protect
11n frames, including A-MPDU frames.

Tested:

* Intel 5100, STA mode

(more) correctly account TX completion status for A-MPDU session frames.

The rules turn out to be:

* for non-aggregation session TX queues - it's either sent or not sent.
* for aggregation session TX queues - if nframes=1, then the status reflects
the completed transmission.
* however, for nframes > 1, then this is just a status reflecting what
the initial transmission did. The compressed BA (immediate or delayed)
may not have yet been received, so the actual frame status is in the
compressed BA updates.

Whilst here, I fiddled with debugging and formatting a bit.

There's also RTS attempts (what the atheros chips call "short retries")
which weren't being logged and they aren't yet being used in the rate
control statistics updates. For now, at least log them.

TODO:

* This still isn't 100% correct! So I have to tinker with this some more.
(The failures aren't always failures..)
* Extend the rate control API in net80211 so it can take both short and
long retry counts.

Tested:

* Intel 5100, STA mode

Bring over some more status codes from the Linux iwlwifi driver.

The (eventual) intention is to create MIB counters for transmitted
frame completion to count how many packets with each status are
transmitted.

Note the difference between A-MPDU and non A-MPDU status.

Obtained from: Linux iwlwifi/dvm driver

Inform the rate control code if a single frame AMPDU transmission succeeds
but has some retries.

Without this, single frame transmission in AMPDU will always look like
it succeeded fine, and thus AMRR will think it's totally fine to just
keep upping the rate upwards.

Now, this is still not quite right! For multi-frame aggregates the
completion happens in two parts - the TX done and the BA received.
The driver is currently double accounting those a little - there's no
way to say to the rate control code "I completed X frames, Y worked fine,
there were Z retries." And it's a bit odd with iwn, as the firmware
retransmits frames for us so we don't get to see how many retransmits
happened; only that it took longer than normal. I may have to extend
the rate control API to properly track that.

So this may keep the rate lower than it should be, but that's better
than keeping it higher than it should be.

Tested:

* 5100, STA mode

Fix antenna configuration, microcode version checks and rate selection
in preparation for the 5300 3x3 NIC.

During this particular adventure, I did indeed discover that a whole
swath of things made little to no sense.

Those included, and are fixed here:

* A lot of the antenna configuration bits assume the NIC has two receive
chains. That's blatantly untrue for NICs that don't.
* There was some disconnect between the antenna configuration when
forming a PLCP rate DWORD (which includes the transmit antenna
configuration), separate to the link quality antenna configuration.

So now there's helper functions to return which antenna configurations
to use and those are used wherever an antenna config is required.

* The 5300 does up to three stream TX/RX (so MCS0->23), however
the link quality table has only 16 slots. This means all of the
rate entries are .. well, dual-stream rates. If this is the case,
the "last MIMO" parameter can't be 16 or it panics the firmware.
Set it to 15.

* .. and since yes it has 16 slots, it only would try retransmitting
from MCS8->MCS23, which can be quite .. terrible. Hard-code the last
two retry slots to be the lowest configured rate.

* I noticed some transmit configuration command stuff is different
based on firmware API version, so I lifted that code from Linux.

* Add / augment some more logging to make it easier to capture this
stuff.

Now, 3x3 is still terrible because the link quality configuration is
plainly not good enough. I'll have to think about that.
However, the original goal of this - 3x3 operation on the Intel
5300 NIC - actually worked.

There are also rate control bugs in the way this driver handles
notifying the net80211 rate control code when AMPDU is enabled.
It always steps the rate up to the maximum rate possible - and
this eventually ends in much sadness. I'll fix that later.

As a side note - 2GHz HT40 now works on all the NICs I have tested.

As a second side note - this exposed some bad 3x3 behaviour in
the ath(4) rate control code where it starts off at a 3-stream rate
and doesn't downgrade quickly enough. This makes the initial
dhcp exchange take a long time. I'll fix the ath(4) rate code
to start at a low fixed 1x1 MCS rate and step up if everything
works out.

Tested:

* Intel 2200
* Intel 2230
* Intel 5300
* Intel 5100
* Intel 6205
* Intel 100

TODO:

* Test the other NICs more thoroughly!

Thank you to Michael Kosarev <russiane39@gmail.com> for donating the
Intel 5300 NIC and pestering me about it since last year to try and
make it all work.

Do the iwn(4) panic reinitialisation under IWN_LOCK().

I've checked each of the functions being called and there's either a
_locked version or it's supposed to be called with IWN_LOCK() held.

Shadow RAM support is apparently not at all working on the Intel 5300 Wifi.

Tested:

* Intel 5300 3x3 wifi
* Intel 5100

- Don't check the dma map address for a static DMA mapping against NULL
to determine if the mapping is valid.
- Don't explicitly destroy the dmap map for static DMA mappings.

Reviewed by: adrian

Remove debugging printf that crept in in r266770.

Submitted by: adrian, nwhitehorn
MFC after: 2 weeks

Add support for the Intel Centrino Wireless-N 105 chipset.

MFC after: 2 weeks
Relnotes: yes

Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens. Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by: adrian@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Erm, revert r266544; wrong tree.

Make iwn(4) able to get itself back into working condition after
"fatal firmware error" happens. Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".

Approved by: adrian@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation

Fix the required calibration flags for the Centrino 1000 NIC.

Add a missing comma between error message definitions.

CID: 1199266
Found with: Coverity Prevent(tm)
MFC after: 1 week

Handle the newer-style bluetooth message format from the (at least)
Centrino 2230 firmware.

This fixes the general statistics block to be actually valid.

I've verified this by contrasting the output of iwnstats before and
after the change. The general block is now correct.

Tested:

* Intel 5100 (old format stats message)
* Intel 2230 (new format stats message)

Add the bluetooth information structs to the firmware RX statistics message.

It turns out that there's a variant format of the RX statisitcs notification
from the intel firmware. It's even more whacked - the non-BT variant has
bluetooth fields; apparently some later NICs return even _more_ bluetooth
related fields.

I'll commit the statistics structure changes here - it's a no-op for the
driver. I'll later teach the driver code to populate a statistics structure
from the received message after reformatting things correctly.

I don't _think_ it's going to fix anything related to sensitivity programming
as the CCK/OFDM (non-11n) fields are in the same place for both formats.
But the HT structure and the general statistics aren't in the same place.

I'll go find some NIC(s) that spit out the other format and when I find one,
I'll go and update the driver to handle things correctly.

Tested:

* Intel 5100 (which returns the legacy, non-BT format)

Obtained from: Linux iwlwifi

Track and expose the latest statistics from the firmware.

Tested:

* Intel Centrino 6205

Reserve a bit for statistics debugging. I'll hopefully use it soon.

Fix a typo.

Fix indentation.

Add support for the Intel Centrino Wireless-N 135 chipset.

MFC after: 2 weeks

Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.

The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.

Reviewed by: adrian, rpaulo

Move the retune notification print to a debug print.

Yes, I still have to do the retune. But I'm giving in to many people
pestering me (very gently!) about this.

Tested:

* Intel Centrino 6205

- Probe with BUS_PROBE_DEFAULT instead of 0.
- Remove clearing PCIM_CMD_INTxDIS; pci(4) will do that as appropriate since
r189367.

MFC after: 1 week

- There's no need to keep track of resource IDs.
- Simplify MSI allocation and release. For a single one, we don't need to
fiddle with the MSI count and pci_release_msi(9) is smart enough to just
do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.

MFC after: 1 week

Fix the Intel 6150 support.

This chip doesn't require the temperature sensor offset, either v1 or
v2. Doing so causes the initial calibration test to fail.

Tested:

* Intel Centrino 6150

Add some initial support for the Intel 6235.

Tested:

* Intel 5100
* Intel 6235

Obtained from: mav, others

Refactor out the scan id and scan vap as part of the scan work.

Make the scan state optional - we'll obviously need a vap, but we now
won't require the scan state. the only thing the scan state is needed
for is to check for the list of SSIDs to scan - which we can now
just plain ignore by passing in NULL as the scan state pointer.

Tested:

* Intel 5100 (STA)

Add a channel parameter to iwn_scan().

This is in preparation for being able to use iwn_scan() to do an off
channel scan to reset the RF tuning.

It should be a no-op.

Tested:

* Intel 5100 (STA)

Refactor out the scan channel to be assigned early on in iwn_scan()
rather than it all being a mess of 'c' and 'ic->ic_curchan'.

Tested:

* Intel 5100 (STA)

Begin fleshing out some code to handle tracking PLCP error rates
in preparation for the scan based retune logic.

The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.

* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
threshold.

The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)

Tested:

* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)

Add some PLCP thresholds from Linux iwlwifi driver in preparation for
working on some RF tuning issues.

The linux iwlwifi driver has these thresholds which they use to see
if there are PLCP errors over a certain interval. If they hit this,
they trigger a single-channel (different from active channels!)
scan to retune the RF front-end.

* Sort the copyright lines by date
* Ok ok, I've touched this enough to claim part of it.

Overhaul the iwn(4) scan infrastructure to be slightly more "correct"
for these chipsets.

* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.

* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.

* For now, hardcode the scan service_time. It's defined as:

31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.

When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.

For now it's 4 beacon intervals and 100 microseconds.

* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.

* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.

* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.

Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.

This is a work in progress; please let me know if things get stuck or
if things improve!

Tested:

* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)

Obtained from: linux iwlwifi

Log the rx ring offset as part of the debug message.

Oops - fix bad indent. Sorry!

Add some sanity checks to the TLV fetch.

Obtained from: Linux iwlwifi

Add some code to double-check whether we're correctly populating the
TX ring according to what the firmware requires.

The firmware requires A-MPDU sub-frames to be at a very specific ring
offset - that is, the ring slot offset should be (seqno % 256.)

This holds for every NIC I've tested thus far except the 4965,
which starts erroring out here shortly before the firmware panics.
Which is good, it's doing what it's supposed to (read: capture that
we've screwed up somewhere.)

The specifics about getting this stuff right:

* the initial seqno allocation should match up with the ringid.
* .. yes, this means we can start at a ring offset that isn't zero.
* .. because we program the start seqno in the firmware message
to setup the AC.
* The initial seqno allocation may be non-zero _and_ frames may be
being transmitted during a-mpdu negotiation. I faced similar
issues on ath(4) and had to software queue frames to that node+TID
during A-MPDU negotiation.
* seqno allocation should be in lockstep with ring increments.
* If we fail to transmit some segment, no, we shouldn't reuse that
ring slot. We should just transmit a BAR (which we aren't yet
doing, sigh) and move onto the next seqno.
* In theory there shouldn't be any holes in the seqno space when
we are transmitting frames.

Tested:

* 4965 (throws problems, so yes we have to fix this);
* 5100 (seems ok);
* 6200 (seems ok);
* 2200 (seems ok);
* 2230 (seems ok).

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.

This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.

A similar change was made in OpenBSD.

Discussed with: -arch, rdivacky
Reviewed by: cperciva

Disable this debugging - it's far too verbose when doing TX rate debugging.

Use the correct endian-ness accessor for this TLV field.
(It's coming from firmware and thus it's defined as little-endian.)

Add definitions for the microcode TLV flags entry (type 18.)

This isn't used anywhere just yet!

Obtained from: Linux iwlwifi

Add a new debug section.

Centrino Wireless-N 2200 does not have bluetooth support.

Fix (I think!) the scan timeouts on the intel NICs.

This field needs to be (a) set, and (b) greater than the other timeouts
(passive, active, maxquiet, etc.) It also is in microseconds, not
milliseconds.

I hope this will fix the scan hangs that people are seeing.

Obtained from: Linux iwlwifi

This is "scan_flags" from Linux.

Leave a note that the 5300 is a 3x3 NIC.

Correctly initialise the 2-chain antenna mask in the link quality table.

The previous code simply hard-coded IWN_ANT_AB which is only correct for
some of the NICs.

Now, if the NIC is a 1-stream TX, you need to set IWN_ANT_AB and _not_
just a single antenna. The Intel 5100 firmware panics the moment the
link quality table is updated.

So!

* no secondary antenna? Set it to IWN_ANT_AB;
* two-stream device? Transmit on the full transmit antenna configuration.

Tested:

* Intel 5100, STA
* Intel 2200 (eadler)

Obtained from: Linux iwlwifi

Commit over some work to prepare the iwn(4) driver for further chipset
support.

* Extend the hardware base_params structure to include a bunch of hardware
flags indicating what is and isn't supported.

* Convert a bunch of the initial hardware configuration conditionals to
consult the base_params structure.

* Add new calibration code for temperature calibration for the Centrino 2xxx
series NICs.

* Add new bluetooth coexistence code for Centrino 2xxx series NICs.

* For NICs that support PAN (personal area networking), use a different
transmit queue and command queue setup, in preparation for said
PAN support.

* Extend the calibration array in iwn_softc to include enough space for
the new calibration types.

Tested (by myself, if not mentioned):

* Intel 4965
* Intel 5100
* Intel 6150
* Intel 2230
* Intel 2200 (eadler)
* Intel 1030
* Intel 6200
* Intel 6230
* Intel 6250
* Intel 6150
* Intel 100

What doesn't work:

* Intel 6235 - fails in calibration at startup

TODO:

* Testing on Intel 53xx series hardware

Submitted by: Cedric Gross <cg@cgross.info>

Fix up the link quality lookup and re-enable multi-rate retry.

This is a terrible solution that at least behaves mostly correctly.

It walks the currently active rate table looking for rates to match.
It assumes that the code matches the setup path in the link quality
setup code (much like the previous, much simpler but even more hackish
math did.)

It's O(n), but n<15, so we're okay for the time being.

Tested:

* Intel 5100, STA - 11a, 11n, 11bg modes.

Grr. For some odd reason, setting this to a single antenna on my 5100
(which is a 1x2 device) panics the firmware.

But, for some 6xxx devices that require IWN_ANT_BC for the TX chainmask,
the link quality entries need to represent _that_.

So, revert this for now until I can figure out what is supposed to be
going on.

Use the negotiated HT rate set when generating the link quality table.

Comment what 'mimo' does in the link quality table.

Don't default to antennas A+B; some NICs use Antennas B+C to transmit.

If A-MPDU transmission fails entirely, then no BA is received from the
NIC and pushed up to the driver. Unfortunately this means there's
no rate control notification done. Thus, if the rate control code
makes a decision that hits a crappy rate that can't succeed, the
rate code would never lower the rate and packet loss would continue.

So, fake some rate control notification in this case.

Replace the hard-coded RX queue value check with IWN_UNSOLICITED_RX_NOTIF.

Fix off-by-one. Sorry!

Use IWN_NBANDS rather than a hard-coded limit.

Tested:

* Intel 5100, STA

Send EAPOL frames at the management rate, not the data rate.

Without this, a far away station with low signal strength would
associate using the management rate (by default the lowest rate)
and then the EAPOL frames would go out at the current AMRR best
guess. This would result in association failing authentication.

Tested:

* Intel 5100, STA
* Intel 2230, STA

Add some new driver definitions as part of the chip support updates:

This is a no-op for now!

* Add a new flag value for "there are no extra bits" for some random
field;

* Add a definition for the maximum number of calibration entries in
the calibration data cache in iwn_softc. It's not yet used.

* Add regulatory bands for the 2030 NIC.

Submitted by: Cedric Gross <cg@cgross.info>

Add Bluetooth/PAN (personal area networking) commands.

Submitted by: Cedric Gross <cg@cgross.info>

Add device ids for the Centrino 2x00 devices.

Submitted by: Cedric Gross <cg@cgross.info>

Remove trailing whitespace.

Submitted by: Cedric Gross <cg@cgross.info>

Don't base the rate table selection based on the channel mode;
it needs to check whether there are rate entries in there or not.

PR: kern/183428

Fix the PLCP lookup code in iwn(4) to base the 11n decision on whether
the rate is 11n, rather than whether the channel is 11n.

This correctly allows the PLCP lookup code to return the legacy rates
even on an 11n channel.

PR: kern/183430

The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

add 0x8b, lifted from Linux iwlegacy/commands.h

This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.

Obtained from: Linux drivers/net/wireless/iwlegacy

Begin fleshing out a knob to enable/disable bluetooth coexistence.

Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.

Tested:

* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)

Temporarily disable multi-rate retry (link quality) and eliminate rate
index lookups.

* My recent(ish) change to iwn(4) and the net80211 rate control API to
support 11n rates broke the link quality table use. So, until I or
someone else decides to fix it, let's just disable it for now.

* Teach iwn_tx_data_raw() to use the iwn_rate_to_plcp() function.

* Eliminate two uses of the net80211 rate index lookup functions - they
are only for legacy rates and they're not needed here.

This fixes some invalid looking rate control TX issues that showed up
on my 4965 but it doesn't fix the two TX hangs I've noticed. Those look
like DMA related issues.

Tested:

* 4965, STA mode
* 5100, STA mode

Break out the debug code into a new include file in preparation for
some more iwn work.

Add #ifdef wrapper around definitions so they aren't included multiple
times.

Migrate iwn(4) to use the new ieee80211_tx_complete() API.

Tested:

* Intel 5100, STA mode

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI
command register. The lazy BAR allocation code in FreeBSD sometimes
disables this bit when it detects a range conflict, and will re-enable
it on demand when a driver allocates the BAR. Thus, the bit is no longer
a reliable indication of capability, and should not be checked. This
results in the elimination of a lot of code from drivers, and also gives
the opportunity to simplify a lot of drivers to use a helper API to set
the busmaster enable bit.

This changes fixes some recent reports of disk controllers and their
associated drives/enclosures disappearing during boot.

Submitted by: jhb
Reviewed by: jfv, marius, achadd, achim
MFC after: 1 day

Use the correct structure size when flipping the BT coex state machine.

This showed up when doing some basic testing on the Intel 6230.

Tested:

* Intel 6230, STA mode

Prepare for the PAN (personal area network) support for iwn(4).

* Break out the single, static RX context into a pointer, and ..
* .. extend it to two RX contexts - a default and a PAN context.

Whilst here, add a few extra fields in preparation for further iwn(4)
work.

Tested:

* Intel 4965, STA mode - same level of stability
* Intel 5100, STA mode - no change

Submitted by: Cedric Gross <cg@gross.info>

Cap the number of streams supported to two for now.

I haven't yet reviewed the Intel driver(s) in more depth to see if
there are 1x1 NICs that report they support 2 transmit/receive chains..
if so then we'll have to update this.

Tested:

* Intel 4965, which is a 2x2 device with 3 RX and 2 TX chains.

PR: kern/181132

Fixing a typo.

Approved by: sbruno (mentor, implicit)

Add in some definitions required for later iwn(4) device support.

This also clarifies a few existing fields.

Tested:

* Intel 5100

Submitted by: Cedric GROSS <cg@gross.info>

Break out the iwn(4) device IDs into if_iwn_devid.h, as well as add
IDs for new devices.

* Add new device IDs
* Extend the ID probe code to include the newer range of bits used
by later model devices

Tested:

* Intel 5100, STA mode

TODO:

* Test on Intel 4965, just to be sure

Submitted by: Cedric GROSS <cg@gross.info>

Now that conf/options knows about if_iwn.h, add it to if_iwn.c.

This allows for IWN_DEBUG (and maybe more stuff later) to be a build
time configure option.

iwn(4) debugging improvements.

* Add in some new register debugging under IWN_DEBUG_REGISTER
* Make IWN_DEBUG an option now for building. I'll chase this up
with a commit to 'options' soon.

Submitted by: Cedric GROSS <cg@cgross.info>

Implement some function tracing.

Submitted by: Cedric GROSS <cg@cgross.info>

Support setting up the iwn debug flags during probe/attach by
checking "hint.iwn.X.debug".

Submitted by: Cedric GROSS <cg@cgross.info>

Add new IDs for The Intel 2230 wireless NIC.

Submitted by: Cedric GROSS <cg@cgross.info>

Implement basic 802.11n awareness in the PHY and AMRR rate control code.

* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
MCS23 rates (3x3.)

* Populate the rate code -> rate index lookup table with MCS _and_
normal rates, but _not_ the basic rate flag. Since the basic rate flag
is the same as the MCS flag, we can only use one.

* Introduce some accessor inlines that do PLCP and rate table lookup/access
and enforce that it doesn't set the basic rate bit. They're not
designed for MCS rates, so it will panic.

* Start converting drivers that use the rate table stuff to use the
accessor inlines and strip the basic flag.

* Teach AMRR about basic 11n - it's still as crap for MCS as it is
being used by iwn, so it's not a step _backwardS_.

* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
to MCS rates. It doesn't use a lookup table any longer; instead it's a
function which takes the current node (for HT parameters) and the
rate code, and returns the hardware PLCP code to use.

Tested:

* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n

Enable the station-side power management flag.

It's not enabled by default in net80211 so this is a no-op unless
if you enable it (ifconfig wlan0 powersave).

Tested:

* iwn0: <Intel WiFi Link 5100> mem 0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3

TODO:

* .. test on all the other NICs
* See if I have to disable it during scan and such
* Make it configurable live, rather than only after it's done its initial
receive calibration.

Fixing incorrect id for Intel Centrino Wireless-N 130.

PR: kern/180094
Submitted by: Cedric <cg@cgross.info>
Approved by: sbruno (mentor)
MFC after: 3 weeks

Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.

Include opt_wlan.h so the net80211 RX debug API compiles correctly.

fix a panic resulting from a stray '&'

MFC after: 1 week

We need to defer passing the DELBA request to the firmware until the aggr
queue is empty or the firmware will go nuts.

PR: kern/167806
Tested by: osa@, Brandon Gooch (earlier version),
Bojan Petrovic (earlier version)
MFC after: 3 days

Fix a TX aggregation issue, if after the last compressed BA notification
the TX queue is empty, there won't be a TX done notification, effectly
resulting in an mbuf leak. The correct way to handle this is to free
up mbufs on both BA and TX done notifications up to the last sent seqno.

Tested by: osa@
MFC after: 3 days

Remove nitems() now that it lives in <sys/param.h> since r236486.

remove unused vap variable

MFC after: 1 week

Discard frames after a DELBA which where queued during an active BA
session.

MFC after: 1 week

Add some more 100/130 series device IDs.

MFC after: 3 days

Migrate the net80211 TX aggregation state to be from per-AC to per-TID.

TODO:

* Test mwl(4) more thoroughly!

Reviewed by: bschmidt (for iwn)

Use the M_AMPDU_MPDU flag to determine when to manually set the seqno and
use a BA queue.

strip (R) to match manpage and pci_vendors

MFC after: 1 week

Add support for 6150 series devices.

Tested by: Shane Riddle <sh4neriddle at yahoo dot com>
MFC after: 1 week

Use suspend/resume methods provided by net80211. This ensures that the
appropriate state handling takes place, not doing so results in the
device doing nothing until manual intervention.

Reviewed by: iwasaki
Tested by: iwasaki (iwi)
MFC after: 4 weeks

On state changes from RUN to anything else the AGGR sessions are
cleared/dropped leading to qid2tap[n] being NULL as there no longer
is a tap. Now, if there have been lots of frames queued the firmware
processes and returns those after the tap is gone.

Tested by: osa
MFC after: 1 week

Don't rely on MCS7 being at index 7 while determining the amount
of antennas to use. Not all APs enable all MCS rates.

Poked by: Lucius Windschuh <lwindschuh at googlemail dot com>
MFC after: 1 week

Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
compiler warnings

Submitted by: arundel@

The DC calibration result obtained during initialization can't be
passed over to the runtime firmware on 6050 devices. Instead let
the runtime firmware do the calibration itself. This fixes support
for the 6050 series devices.

Obtained from: OpenBSD
Submitted by: kevlo
Tested by: lx, Tz-Huan Huang(earlier version)

Let net80211 also know about stopped BA sessions. This fixes some issues
where the driver assumed that BA resources are still available due to
net80211 saying so.

PR: 161407, 159768
Tested by: cperciva, rene
MFC after: 3 days

Fix bmiss notifications, events should be sent when NOT scanning.

MFC after: 3 days

Recognize the Intel(R) Centrino(R) Wireless-N 130.

PR: 161162

Manually set the channel when using monitor mode - the firmware
doesn't select it automatically.

Submitted by: nox
Reviewed by: bschmidt
Approved by: re
PR: kern/160815

Make sure to drop the IEEE80211_RATE_BASIC flag even for MCS rates.

Reported by: Maciej Milewski <milu at dat dot pl>
Tested by: Maciej Milewski <milu at dat dot pl>

Enable HT40 (40MHz channel width) support.

Only consider QoS frames for TX packet aggregation.

The firmware of 4965 series adapters seems to die while trying to send
probe requests at 1Mbps while being associated on a 5GHz channel. Sending
those at 6Mbps does work, so use that instead during a background scan.
This workaround allows us to re-enable background scan support for the
4965 adapters.

Also, just enabling one antenna on 5GHz results in better reception of
beacons:
test 00:26:5a:c6:14:1a 40 54M -71:-95 200 E WME HTCAP ATH
vs
test 00:26:5a:c6:14:1a 40 54M -92:-95 200 E WME HTCAP ATH
Due to roam:rssi thresholds set to 7 by default it might have been
impossible to associate to that network. While here use
IEEE80211_IS_CHAN_5GHZ() to determine the band.

Add module version to iwi/ipw/wpi and iwn.

The version is used to check if a module is already preset, not setting
it results in:

can't re-use a leaf (ipw)!
module_register: module pci/ipw already exists!
Module pci/ipw failed to register: 17

while trying to load the module due to an entry in loader.conf. With this
commit we get the expected:

module ipw already present!

Reported by: Dru Lavigne, bz
Tested by: bz
MFC after: 1 week

Only update the scheduler's byte count table for aggregation queues.
The other queues, especially the command queue, uses the FIFO mode
which doesn't require the byte count table because queued entries are
processed in order.

Pointed out by: Lucius Windschuh <lwindschuh at googlemail dot com>

Enable 11n (sans HT40) support.

Notify firmware about various HT parameters once associated.

Add support for TX packet aggregation.

Add support for RX packet aggregation.

Add support for transmitting frames at MCS rates.

Prepare for transmitting frames at MCS rates:
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std

Read chainmask information before announcing it.

Add HT capabilities to probe requests.

Disable background scan support for 4965 adapters.

On legacy channels every once in a while the firmware throws a SYSASSERT
on line 208. On HT channels though this does always happen and I'm not
aware of any workaround currently.

RX aggregation is slightly different then the legacy path, we will only
receive one RX_PHY for each aggregate and not one RX_PHY per frame.

Allocate all TX rings, those will be use for TX packet aggregation.

Use the enhanced TX power information availabe on newer EEPROMs.

Hook HT channel setup.

The 6000 series adapters have a slightly different offset for band 6,
2GHz HT40 channels.

Re-add 2 device IDs which got lost.

Pointed out by: benjsc

Now that all bits are in for 1030/6230 adapters enable those.
While here pull the adapter names from the Linux driver and sort
the list by ID.

The 6000 series gen2 adapters have 2 firmware images, one with
advanced btcoex support and one without.

Add basic support for advanced bluetooth coexistence required
for 6005 gen2b (1030/6030) adapters.

Enable DC calibration for all 6000 series devices, except those
with an internal PA.
Override the chainmask also for the 6050.

Pull some features out of the firmware:
- If a ENH_SENS TLV section exit the firmware is capable of doing
enhanced sensitivity calibration.
- Newer devices/firmwares have more calibration commands therefore
hardcoding the noise gain/reset commands no longer works. It is
supposed to use the next index after the newest calibration type
support. Read the command index of the TLV section if available.

Add some new features:
- 6000 series devices need enhanced sensitivity calibration.
- 6000 series devices need a different setting for the shadow reg.
- set the IWN_FLAG_HAS_11N bit if the EEPROM says the device has 11n
support.

Obtained from: OpenBSD

Bring over the HAL/OPS changes, instead of two const structs it is now
slightly more dynamic.

Obtained from: OpenBSD

Read RX/TX chainmasks directly of the EEPROM. Some chips are known to
have the wrong/broken information stored, keep the hardcoded values for
those.

Obtained from: OpenBSD

Just a whitespace sync, some more style(9) conform then others.

Sync comments with OpenBSD.

Sync debug and error messages with OpenBSD.

Shuffle code around a bit. Mostly to group functional connected things,
others to get the same order as the OpenBSD code.

Rename some stuff in favour of the OpenBSD names:
- prefer EDCA over WME
- qid for a TXQ ID
- reg for register values

Fix WME/QoS handling:
- move the TX queue selection into iwn_tx_data/iwn_tx_data_raw
- extract traffic identifier and use it
- do not expect ACKs for frames marked as such

Remove if_ierrors which do not necessarily indicate a RX error, also
do account send packets. While here use the IWN_TX_FAIL constant.

Instead of hardcoding TX rates and using that to fill the retry table
use the neogotiated ni_rates instead.

Replace RX/TX ring allocation error messages with something more sane
and remove those where the caller already prints one.

Prevent double-free, also use the same error codes as OpenBSD.

Add missing bus_dmamap_sync calls as well as remove two duplicate ones.

Obtained from: OpenBSD

Unify TX/RX ring allocation, finish the descriptior DMA stuff before
starting with data.

Make sure to destroy all DMA tags and maps.

Rewrite DMA segment handling to be more inline with the OpenBSD code.
Also change the m_len == 0 hack to have less code churn.

scratch_paddr has the same address pre-assigned, use that instead.

In case a new mbuf can't be loaded, reuse the old one.

OpenBSD uses IWN_RBUF_SIZE not MJUMPAGESIZE for the RX path, also replace
caddr_t with void * to be in sync.

Remove the flags argument of iwn_dma_contig_alloc(), it is always set
as BUS_DMA_NOWAIT. While here also set BUS_DMA_COHERENT.

RSSI related syncs with the OpenBSD code:
- read RSSI only for the active chains
- cast RSSI/NF to int8_t before passing it up to radiotap
- remove the htole64() for the timestamp

Obtained from: OpenBSD

Pass errors that might happen during state transitions up to net80211.

Obtain the channel number directly from the laster RXON command, also
chan is an uint8_t.

fix the order of the prototypes from the previosu commit

The 6005 series devices need additional temperature offset calibration
as well as the IWN_GP_DRIVER_CALIB_VER6 bit set.

Obtained from: OpenBSD

Revert some of local calibration changes in favour of the OpenBSD
implementation. This includes the fix required for the 6050 series
devices.

remove debug left-overs

Split up watchdog and calibration callout. This allows us to use different
timing on both and to remove some monitor mode specific hacks (which has
no calibration).

Split out bluetooth coexistence setup.

Fixes for firmware handling:
- there is a local variable for sc->fw_dma, use that instead
- OpenBSD uses 5*hz to wait for firmware to be loaded
- in case the firmware module contains invalid data, actually release it

Only handle beacon misses while in RUN state and not scanning.

Don't timeout when stopping DMA channels.

Obtained from: OpenBSD

Instead of trying to figure out which rxon.flags to clear, restart
from scratch. Remove htole16() calls, rxon.chan is an uint8_t,
ieee80211_chan2ieee() does return an ic_ieee as an int, but I heavily
doubt a htole16() will buy us anything here.

iwn_cleanup() is just a wrapper around iwn_detach(), call it directly
instead.

Reuse net80211 code:
- IWN_TXOP_TO_US is equal to IEEE80211_TXOP_TO_US
- use IEEE80211_DUR_TU
- ieee80211_add_rates/ieee80211_add_xrates are public, use em
- copied ieee80211_add_ssid it is not public

Remove IWN_FLAG_HAS_5GHZ and IWN_PCI_BAR0, both unused.

Do a sweep of the tree replacing calls to pci_find_extcap() with calls to
pci_find_cap() instead.

Pull ieee80211_ratectl_node_init() calls from drivers into net80211.
This fixes hostap mode for at least ral(4) and run(4), because there is
no sufficient call into drivers which could be used initialize the node
related ratectl variables.

MFC after: 3 days

Fixes for monitor mode:
- Do not call iwn_calib_reset() for monitor mode. We do not want to query
information and do runtime calibration while in monitor mode. Poking the
firmware with adjustments for calibration results in firmware asserts.
This could happened on RUN -> RUN transition only.
- Adjust blink rate for monitor mode. It's supposed to not freak out and
turn off after a while.
- While here, remove one useless assignment of calib.state, it gets
overwritten later in the function.

Submitted by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 1 week

For 6000 series and newer devices the DC calibration results are no
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.

MFC after: 1 week

Instead of using the AMRR ratectl algo as default for drivers which have
the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if
a driver calls ieee80211_ratectl_init() check if the NONE algo is still
selected and try to use AMRR in that case. Drivers are still free to use
any other algo by calling ieee80211_ratectl_set() prior to the
ieee80211_ratectl_init() call.

After this change it is now safe to assume that a ratectl algo is always
available and selected, which renders the IEEE80211_C_RATECTL flag pretty
much useless. Therefore revert r211314 and 211546.

Reviewed by: rpaulo
MFC after: 2 weeks

Fix typo in previous commit.

Rewrite parts of the calibration code which is run while bringing up
the device:
- unobscure some of the code by moving it into its own functions
- get rid of some magic numbers
- create similar structure as the reference driver has, this should
make further syncs easier

Group functions used for initial calibration.

Introduce IEEE80211_C_RATECTL, drivers which use the ratectl framework
should set this capability.

MFC after: 2 weeks

Handle RUN->ASSOC->RUN transition correctly, as in not trigger a
firmware error. Convert if statements to a switch statement while
I'm here.

Tested by: Benjamin Kaduk <kaduk at mit.edu>
MFC after: 2 weeks

Add support for firmware images in "type-length-value" format.

Obtained from: OpenBSD
MFC after: 2 weeks

Detect active chains differently to work around a firmware bug which
would mark non-existing chains as active.

Obtained from: OpenBSD
MFC after: 1 week

- Add new IDs for 6000 series devices.
- The 6000 series WiMAX devices need a separate firmware.
- The b-gen devices are not hooked because the hardware revision type
is not know.

Obtained from: OpenBSD
MFC after: 1 week

Fix some small whitespace nits.

MFC after: 3 days

Remove duplicate vendor:device entry.

MFC after: 3 days

Fix TX retry rate handling. tx->linkq is an index to a rate table
beginning with the highest available rate. Currently we always use
54m for the first retry no matter what AMRR has choosen. Fix this
by setting the index to the next lower rate.

Approved by: rpaulo (mentor)
Tested by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 2 weeks

Add a workaround for a bug in the firmware regarding the transition
from passive to active scans. Basicly disable it by increasing the
amount packets to be received to an amount which can't be reached
during dwell times.

Approved by: rpaulo (mentor)
MFC after: 3 days

Add new tunable 'net.link.ifqmaxlen' to set default send interface
queue length. The default value for this parameter is 50, which is
quite low for many of today's uses and the only way to modify this
parameter right now is to edit if_var.h file. Also add read-only
sysctl with the same name, so that it's possible to retrieve the
current value.

MFC after: 1 month

Use correct bus_dma_tag_t for TX frames.

Reported by: Andreas Nilsson <andrnils at gmail.com>
Approved by: rpaulo (mentor)
MFC after: 3 days

Declare all functions as static.

Approved by: rpaulo (mentor)
MFC after: 2 weeks

Hook ieee80211_media_change() to ieee80211_vap_attach().

Approved by: rpaulo (mentor)
MFC after: 2 weeks

iwn5000_reset_sched() is not used; #ifdef it.

Approved by: rpaulo (mentor)
MFC after: 2 weeks

Add some missing protoypes.

Approved by: rpaulo (mentor)
MFC after: 2 weeks

iwn4965_set_txpower() uses maxpwr from EEPROM to calculate the power to
set, it make sense to actually initialize that array. This fixes some
issues with 4965 adapters where the TX power is crucial.

This got lost somewhere while merging with the OpenBSD code.

Approved by: rpaulo (mentor)
Obtained from: OpenBSD
MFC after: 2 weeks

* Rename bluetooth coexistence flags, no binary change.
* Enable DC calibration and crystal calibration on Centrino Advanced-N
6250 parts.
* Workaround for a HW bug (does not affect 4965AGN) that may sporadically
affect latency under some rare circumstances. From a similar commit to
iwlwifi.
* Update sensitivity settings for 5000 series to workaround a performance
bug in the DSP (1000 is not affected so we keep the old values for 5000).
* Update sensitivity settings for 6000 series.
* Set differential gains on 6250 too (but use a 1.0 factor, not 1.5).
* Init OFDM sensitivity with min value (which depends on the chip)
instead of hardcoding it to 90.
* Read calibration version from ROM and set IWN_GP_DRIVER_CALIB_VER6
bit on 6x50 if version >= 6.

Approved by: rpaulo (mentor)
Obtained from: OpenBSD
MFC after: 2 weeks

Small whitespace cleanup.

Approved by: rpaulo (mentor)
MFC after: 2 weeks

net80211 rate control framework (net80211 ratectl).

This framework allows drivers to abstract the rate control algorithm and
just feed the framework with the usable parameters. The rate control
framework will now deal with passing the parameters to the selected
algorithm. Right now we have AMRR (the default) and RSSADAPT but there's
no way to select one with ifconfig, yet.
The objective is to have more rate control algorithms in the net80211
stack so all drivers[0] can use it. Ideally, we'll have the well-known
sample rate control algorithm in the net80211 at some point so all
drivers can use it (not just ath).

[0] all drivers that do rate control in software, that is.

Reviewed by: bschmidt, thompsa, weyongo
MFC after: 1 months

Fix for the Intel WiFi Link 1000. The EEPROM image is in the OTPROM block
before the last block, not in the last block itself.

Approved by: rpaulo (mentor)
Obtained from: OpenBSD
MFC after: 3 weeks

o add more notification strings in iwn_intr_str()
o sync with OpenBSD code

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>
MFC after: 3 days

Revert iwn channel-argument handling of set_txpower() to r201822

Pass the channel argument as a real argument and not through
RXON. The RXON version seems to have problem with both the older
228.57.2.23 firmware and the latest 228.61.2.24 version resulting
in device initialization errors like:

wpa_supplicant[2928]: Failed to initiate AP scan.
kernel: firmware error log:
kernel: error type = "SYSASSERT" (0x00000005)
kernel: program counter = 0x0000147C
kernel: source line = 0x0000058B
kernel: error data = 0x0000058B00000000
kernel: branch link = 0x0000145A00001492
kernel: interrupt link = 0x000006DE00000000
kernel: time = 7310
...
kernel: iwn0: iwn_config: could not set TX power
kernel: iwn0: iwn_init_locked: could not configure device, error 35

By passing the current channel to hal->set_txpower() the firmware
error is fixed, at least for the 4965 chipset of my Thinkpad and
the ones tested by Bernhard.

Submitted by: Bernhard Schmidt <bschmidt@techwires.net>
Approved by: rpaulo

Fix array overflow.

Reviewed by: rpaulo

iwn(4) update. Notable changes:
* new firmware
* untested support for 1000 and 6000 series
* bgscan support
* remove unnecessary RXON changes
* allow setting of country/regdomain by enforcing channel flags read
from the EEPROM
* suspend/resume fixes
* RF kill switch fixes
* LED adjustments
* several bus_dma*() related fixes
* addressed some LORs
* many other bug fixes

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>
Obtained from: Brandon Gooch <jamesbrandongooch at gmail dot com> (LED
related changes), Benjamin Kaduk <kaduk at mit dot edu>
(LOR fixes), OpenBSD

Updates to the iwn driver:
* iwnfw has now been split into individual modules so autoloading of
firmware module(s) does work again.
* Changes have been made to RUN -> AUTH transition, this should fix the
issue reported by Glen and others.
* Brandon reported issues in iwn_cmd() with large commands, those have
been fixed to.
* DEAUTH is now handled correctly.

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>

Updated iwn(4) driver supporting the newer series, 5000, 5150 and 5300.

Submitted by: Bernhard Schmidt <bschmidt at techwires.net>

For ic_opmode switch cases, provide a default label with a printf saying
this opmode is not supported.

Approved by: re (kib)

validate tx rate(s) in the raw xmit path

Tested by: "Paul B. Mahol" <onemda@gmail.com> (rum, bwi)

Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
and remove explicit bpf support from wireless drivers; drivers now
use ieee80211_radiotap_attach to setup shared data structures that
hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
for debugging and was mostly useless due to it being 32-bits and mostly
unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
state and dispatch frames; drivers no longer explicitly directly check
bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
should not do this (unless they bypass net80211 which is almost always
a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by: cbzimmer, rpaulo, thompsa

Abort any scan on a fatal firmware. ic_scan_curchan is overridden to perform
the scan in firmware and this relies on the firmware to wake up the scan task
on completion.

Create a taskqueue for each wireless interface which provides a serialised
sleepable context for net80211 driver callbacks. This removes the need for USB
and firmware based drivers to roll their own code to defer the chip programming
for state changes, scan requests, channel changes and mcast/promisc updates.
When a driver callback completes the hardware state is now guaranteed to have
been updated and is in sync with net80211 layer.

This nukes around 1300 lines of code from the wireless device drivers making
them more readable and less race prone.

The net80211 layer has been updated as follows
- all state/channel changes are serialised on the taskqueue.
- ieee80211_new_state() always queues and can now be called from any context
- scanning runs from a single taskq function and executes to completion. driver
callbacks are synchronous so the channel, phy mode and rx filters are
guaranteed to be set in hardware before probe request frames are
transmitted.

Help and contributions from Sam Leffler.

Reviewed by: sam

Hoist 802.11 encapsulation up into net80211:
o call ieee80211_encap in ieee80211_start so frames passed down to drivers
are already encapsulated
o remove ieee80211_encap calls in drivers
o fixup wi so it recreates the 802.3 head it requires from the 802.11
header contents
o move fast-frame aggregation from ath to net80211 (conditional on
IEEE80211_SUPPORT_SUPERG):
- aggregation is now done in ieee80211_start; it is enabled when the
packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames
are held on a staging queue according to ieee80211_ffagemax
(net.wlan.ffagemax) to wait for a frame to combine with
- drivers must call back to age/flush the staging queue (ath does this
on tx done, at swba, and on rx according to the state of the tx queues
and/or the contents of the staging queue)
- remove fast-frame-related data structures from ath
- add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle
per-node fast-frames state (we reuse 11n tx ampdu state)
o change ieee80211_encap calling convention to include an explicit vap
so frames coming through a WDS vap are recognized w/o setting M_WDS

With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames.

Reviewed by: thompsa, rpaulo, avatar, imp, sephe

Eliminate ic_myaddr so changing the mac address of a device works correctly:
o remove ic_myaddr from ieee80211com
o change ieee80211_ifattach to take the mac address of the physical device
and use that to setup the lladdr.
o replace all references to ic_myaddr in drivers by IF_LLADDR
o related cleanups (e.g. kill dead code)

PR: kern/133178
Reviewed by: thompsa, rpaulo

Remove gratuitous unlock in error case.

Reviewed by: sam

remove references to ic_stats

Spotted by: Lucius Windschuh <lwindschuh@googlemail.com>

o use the new association callback to notify the driver when joining a bss
in sta and adhoc modes; this should've been done forever ago as most all
drivers use this hook to set per-station transmit parameters such as for
tx rate control
o adjust drivers to remove explicit calls to the driver newassoc method

Add MSI support.

Tested on: Acer TravelMate 6292 with 0x4229 chip.
Reviewed by: sam@

Change the calling convention for ic_node_alloc to deal with
some longstanding issues:
o pass the vap since it's now the "coin of the realm" and required
to do things like set initial tx parameters in private node
state for use prior to association
o pass the mac address as cards that maintain outboard station
tables require this to create an entry (e.g. in ibss mode)
o remove the node table reference, we only have one node table
and it's unlikely this will change so this is not needed to
find the com structure

We can not call iwn_start directly in the interrupt
context, where the iwn mutex is being held, and
iwn_start assumes that we do not have that mutex held.

Resolve this issue with what we do for other NICs by
splitting the iwn_start procedure into two parts,
iwn_start() do the locking, and iwn_start_locked()
assumes that the mutex is being held. This resolves
panic when WITNESS is enabled.

Minor cleanup of vap create work:
o add IEEE80211_C_STA capability to indicate sta mode is supported
(was previously assumed) and mark drivers as capable
o add ieee80211_opcap array to map an opmode to the equivalent capability bit
o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's
clear it should be kept in sync (on future additions)
o check device capabilities in clone create before trying to create a vap;
this makes driver checks unneeded
o make error codes return on failed clone request unique
o temporarily add console printfs on clone request failures to aid in
debugging; these will move under DIAGNOSTIC or similar before release

Unify all the wifi *_ioctl routines
- Limit grabbing the lock to SIOCSIFFLAGS.
- Move ieee80211_start_all() to SIOCSIFFLAGS.
- Remove SIOCSIFMEDIA as it is not useful.
- Limit ether_ioctl to only SIOCGIFADDR. SIOCSIFADDR and SIOCSIFMTU have no
affect as there is no input/output path in the vap parent. The vap code
will handle the reinit of the mac address changes.
- Split off ndis_ioctl_80211 as it was getting too different to wired devices.

This fixes a copyout while locked and a lock recursion.

Reviewed by: sam

fix build

Submitted by: delphij

disable HT capabilities until we sort out firmware issues

Intel 4965 wireless driver (derived from openbsd driver of the same name)