* Add the command groups enum, and the iwm_phy_ops_subcmd_ids enum
to if_iwmreg.h definitions.
* The IWM_DTS_MEASUREMENT_NOTIF_WIDE notification will be generated by
version 17 firmware.
Taken-From: Linux iwlwifi
Obtained from: DragonflyBSD commit 4d8d6f9def2ffb60aaf2d88f72f069a96c0b4e3f
* Adds IWM_DEBUG_TEMP debug message type, for printing messages related
to temperature sensors and thermal/TDP infos.
* The firmware regularly sends us DTS measurement notifications, so just
print the temperature value as a debugging message.
(Adrian's addition):
* Eventually this can be used by the driver to limit transmit rate / power to
try and do some thermal throttling.
Obtained from: DragonflyBSD commit efb7d4eb5c3140889a8880e12fd83c7bbfd0059d
* Add iwm_pcie_set_cmd_in_flight() and iwm_pcie_clear_cmd_in_flight()
helper methods.
* Use ring->queued tracking in the command queue to set/clear the
cmd_hold_nic_awake bit at the right points.
Taken-From: Linux iwlwifi
Obtained from: DragonflyBSD commit ce43f57f5308b579ea21e8a5a29969114ba2247d
* Add IWM_FLAG_SCAN_RUNNING to sc->sc_flags to track whether the firmware
is currently running a scan, in order to decide wheter iwm_scan_end
needs to abort a running scan.
* In iwm_scan_end, if the scan is still running, we now abort it, in order
to keep the firmware scanning state in sync.
* Try to make things a bit simpler, by reacting on the
IWM_SCAN_OFFLOAD_COMPLETE and IWM_SCAN_COMPLETE_UMAC notifications,
instead of IWM_SCAN_ITERATION_COMPLETE and
IWM_SCAN_ITERATION_COMPLETE_UMAC. This should be fine since we always
only tell the firmware to do a single scan iteration anyway.
Obtained from: DragonflyBSD commit 1f249c981c4e89e7cde1836a75b61cac36dc7ac5
* Uses the notification wait api to wait for the corresponding scan
complete notification after sending the abort command.
Taken-From: Linux iwlwifi
Obtained from: DragonflyBSD commit b484d09d54301740f036ddf02008117f563960c2
* This also fixes one of many small nic lock handling bugs, and matches
iwlwifi's code.
Obtained from: DragonflyBSD git 50787d03cd0a0366c9cc4a055bb6977e5f65c85d
* This fixes the phy_cfg field sent in the iwm_send_phy_cfg_cmd()
command, which wasn't taking into account the valid_rx_ant and
valid_tx_ant masks from nvm_data before.
Tested:
* 7260, STA mode, 2G and 5G
Obtained from: DragonflyBSD commit cbb82693c18fd71b4eb86855b82d03995f352d65
* This makes it a bit easier to factor out common parts for e.g. the
7000 chipset family.
* Add iwm7265d config, and recognize the 7265D chipset variant via the
hardware revision.
Tested:
* 7260, STA mode (2ghz)
Obtained from: Dragonflybsd commit cc8d6ccf5583fd45964f3bde9b057ee4f834c0e0
* sc->sc_nvm becomes sc->nvm_data and is now a pointer instead of an
inlined struct.
* Add sc->eeprom_size and sc->nvm_hw_section_num configuration values to
struct iwm_softc.
* For now continue to avoid negative error return-values, and use pointer
variables for some return values, as before.
* Continue to omit LAR (location aware regulatory) related code as well.
Tested:
* Intel 7260, STA mode (2GHz)
Obtained from: dragonflybsd commit 39f8331b1a6f295291e08c377da12a8e7a5436c0
This fixes an error handling detail in iwm_nvm_read_chunk(), where an
error response from the firmware for an NVM read shouldn't be fatal if
the offset was non-zero.
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD git 250a1c33fca1725121fe499f9cebc90267d209f9
Differential Revision: https://reviews.freebsd.org/D8542
before calling ieee80211_ifattach() so the taskqueue hasn't been
initialized. Don't try to drain it, we'll panic.
Looks like this issue was introduced in r303326.
Reviewed by: avos, sbruno, adrian
Differential Revision: https://reviews.freebsd.org/D8499
* Starting a scan from wpa_supplicant or via ifconfig while associated,
should no longer cause firmware panics or abort early.
Tested:
* AC7260, STA mode
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8412
* SYNC_RESP_STRUCT and SYNC_RESP_PTR originate from the OpenBSD version of
iwm, and they weren't serving any real purpose in the FreeBSD port.
* We just do a single bus_dmamap_sync for syncing the complete received frame,
instead of explicitly bus_dmamap_sync-ing subranges of the frame like in
the OpenBSD iwm code.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7939
to ieee80211_add_rx_params() + drop last (ieee80211_rx_stats) parameter
Note: there is an additional check for ieee80211_get_rx_params()
return value (which does not exist in the original diff).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8207
There are a variety of more interesting RX statistics that we should
keep track of but we don't. This is a starting point for adding more
information.
Specifically:
* now the RX rate information and some of the packet status is
passed up;
* The 32 bit or 64 bit TSF is passed up;
* the PHY mode is passed up;
* the "I'm decap'ed AMSDU!" state is passed up;
* number of RX chains is bumped to 4.
This is all mostly a placeholder for getting the data into the RX status
before we pass it up to net80211 - unfortunately we don't yet enforce
that drivers provide it, nor do we pass the provided info back up the
stack so anyone can use the data.
We're going to need to use some of this data moving forward.
Notably, now that some hardware can do AMSDU decap for us (the intel iwm
driver can do it when we flip it on; the ath10k port I'm doing does
it for us) then we need to pass it up through the stack so the duplicate
RX sequence numbers and crypto/IV details don't cause the packet to
be dropped and/or counted against a replay counter.
It's also the beginning of being able to do more interesting node
accounting in net80211. Specifically, once drivers start populating
per-packet rate information, AMPDU information, timestamps, etc,
we can start providing histograms of rate-versus-RSSI, account
for receive time spent per node and other such interesting things.
(Note: I'm also hoping to include ranging and RTT information for
future chipset support; and it's likely going to include it in
this kind of fashion.)
Replace various void * / int argument combinations with common structures:
- ieee80211_ratectl_tx_status for *_tx_complete();
- ieee80211_ratectl_tx_stats for *_tx_update();
While here, improve amrr_tx_update() for a bit:
1. In case, if receiver is not known (typical for Ralink USB drivers),
refresh Tx rate for all nodes on the interface.
2. There was a misuse:
- otus(4) sends non-decreasing counters (as originally intended);
- but ural(4), rum(4) and run(4) are using 'read & clear' registers
to obtain statistics for some period of time (and those 'last period'
values are used as arguments for tx_update()). If arguments are not big
enough, they are just discarded after the next call.
Fix: move counting into *_tx_update()
(now otus(4) will zero out all node counters after every tx_update() call)
Tested with:
- Intel 3945BG (wpi(4)), STA mode.
- WUSB54GC (rum(4)), STA / HOSTAP mode.
- RTL8188EU (urtwn(4)), STA mode.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8037
* Don't do the antenna switching when setting up the rate table - we don't
take into account whether it's an active antenna or not (eg shared with BT.)
I'll look into this a bit more later.
* The default antenna is still 1, I'll look into that a bit more later.
(So no, this doesn't fix it for Larry who needs ANT_B to be active, not
ANT_A.)
* My changes to the rate control setup used the wrong method for finding
a suitable rate, which led to 1M CCK frames being queued for 11a operation.
This is .. sub-optimal. Change the rate control lookup path to use
the global table instead of the per-node table, which won't be setup
until the node rate table is setup (which happens way too late in this
game.)
Tested:
* Intel 7260, 2G and 5G operation.
This changes the transmit rate control code to do a few things:
* use fixed rates (mcast, ucast, mgmt) where required.
* Don't use a hard-coded 11a or 11bg rate for non-data frames -
use what net80211 says we should use.
* use mgmtrate for EAPOL frames.
Reviewed by: avos
Differential Revision: https://reviews.freebsd.org/D7994
* We need to first call ivp->iv_newstate(), to enqueue the deauth/deassoc
mgmt frame, then flush the tx queue, before actually calling
iwm_release().
* cycling a wlan connection via wpa_cli frontend to wpa_supplicant, by
issuing disconnect and reconnect commandos works quite well.
(There is still an issue when disconnecting/reconnecting too quickly)
* Reassociating or roaming via wpa_supplicant is still broken.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7943
* No functional change, none of these values were ever read.
* The values removed from struct iwm_nvm_data are only used for old dvm
devices in Linux iwlwifi, and irrelevant to iwm hence.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7945
* This removes deprecated scan API definitions, which have been unused
since the upgrade to version 16 firmware in change r303327.
* Part of this change matches the header-file changes in Linux git commit
1f9403863c080478ad78247c89b018e95bdfb027.
* No functional change.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7937
The iwm(4) iwm_poll_bit() function returns 1 on success, and 0 on failure,
whereas the iwl_poll_bit() in Linux iwlwifi returns < 0 on failure.
So the (ret < 0) check ended up ignoring any error returned by
iwm_poll_bit().
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7932
This fixes a potential buffer overrun in the firmware parsing code.
Reported by: Coverity
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7931
The wantresp field in struct iwm_rx_data has never been used for anything,
so we can just delete it.
Apparently struct iwm_sf_cfg_cmd was compiled correctly (using a 32bit
value to represent the enum), but it still seems like a very bad idea to use
an enum type in a __packed struct.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7930
The htole32 was working fine for little-endian machines, but would have
been broken on big-endian.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7929
* hard code a noise floor of -96 for now. The noise floor update code returns
some "interesting" values that I can't map to anything useful right now.
* Ensure a default noise floor is set - otherwise the initial scan results
have a noise floor of '0'.
* Fix up the RSSI calculation to be correctly relative to the noise floor.
The RSSI routines return an absolute value in dBm - so fix this up.
* Cap RSSI values appropriately.
* Ensure we pass in a 1/2 dB unit value in to net80211.
Tested:
* Intel 7260, STA mode
iwm0: <Intel Dual Band Wireless AC 7260> mem 0xf1400000-0xf1401fff irq 17 at device 0.0 on pci2
iwm0: hw rev 0x140, fw ver 16.242414.0, address xx:xx:xx:xx:xx:xx
* iwm_poll_bit() returns 1 on success and 0 on failure, whereas
iwl_poll_bit() in Linux's iwlwifi returns >= 0 on success and < 0 on
failure.
* Because of the wrong iwm_poll_bit return code check, no warning was
printed if tx DMA stopping failed.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7371
* Makes the TX DMA stopping more similar to Linux code, and potentially
a bit faster. Also, output an error message when TX DMA idling fails.
Taken-From: Linux iwlwifi
Tested:
* AC3165, STA mode
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD git 2ee486ddff973ac552ff787c17e8d83e8ae0f24c
Differential Revision: https://reviews.freebsd.org/D7325
When building a Tx Command for management frames, we are lacking
a check for action frames, for which we should set a different
pm_timeout. This cause the fw to stay awake for 100TU after each
such frame is transmitted, resulting an excessive power consumption.
Taken-From: Linux iwlwifi (git b084a35663c3f1f7)
Approved by: adrian (mentor)
Obtained from: Linux git b084a35663c3f1f7de1c45c4ae3006864c940fe7
Obtained from: DragonFlyBSD git ba00f0e3ae873d6f0d5743e22c3ebc49c44dfdac
Differential Revision: https://reviews.freebsd.org/D7324
The PROT_REQUIRE flag in should be set for data frames above a certain
length, but we were setting it for !data frames above a certain length,
which makes no sense at all.
Taken-From: OpenBSD, Linux iwlwifi
Approved by: adrian (mentor)
Obtained from: DragonFlyBSD git 8cc03924a36c572c2908e659e624f44636dc2b33
Differential Revision: https://reviews.freebsd.org/D7323
