summaryrefslogtreecommitdiffstats
path: root/sys/dev/pci/if_iwx.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* add another iwx devicejcs2021-01-171-10/+19
| | | | ok stsp jsg
* Rename the macro MCLGETI to MCLGETL and removes the dead parameter ifp.jan2020-12-121-3/+3
| | | | | | OK dlg@, bluhm@ No Opinion mpi@ Not against it claudio@
* Fix calculation of "maxlen" if there are multiple MPDUs in one packet.tobhe2020-12-071-8/+2
| | | | | | | | | | Calculating "remain" by subtracting the offset after every parsed MPDU is wrong and not necessary. "offset" always points to the current position in the receive buffer and the maximum size of the buffer is fixed, thus knowing "offset" is sufficient for finding "maxlen". Found by and fix from Christian Erhardt ok stsp@
* Do not write unneeded data into the iwx(4) MAC context removal command.stsp2020-10-221-1/+9
| | | | | | | This extra data seems to trigger an assertion in the firmware and the Linux iwlwifi driver does not send this data either. tested by Nicola Dell'Uomo and jmc@
* Stop exporting `wt_hwqueue' now that drivers don't advertise it.mpi2020-10-111-2/+1
| | | | Pointed by and ok jsg@
* Reset the Rx block ack session counter when an iwm/iwx interface disassociatesstsp2020-08-261-1/+5
| | | | | | | | | | | from an access point or is put down via ifconfig. Otherwise new Rx block ack sessions could be refused upon reassociation due to a bogus counter value. Found by zxystd from the OpenIntelWireless project (drivers for macOS). Testing by jmc@, kevlo@, and Sven Falempin. ok phessler@ mpi@ kevlo@
* Make iwx(4) match any AX200 device again.stsp2020-08-021-12/+2
| | | | | | | | | | | | | | | | | | | In case of AX201 we need to be careful about which devices are matched by the driver because devices with technical differences share the same PCI product ID. The driver must additionally match against a table of known PCI subsystem product IDs to identify an AX201 device correctly. For consistency, I wrote similar matching code for AX200 devices. This matches my AX200 device correctly but fails to recognize some other devices which were previously attached and working. Turns out the Linux driver seems to use AX200 subsystem product IDs merely for marketing purposes. It makes the operating system advertise some AX200 devices with distinct trademarked names. There are no technical differences that concern the driver and there is no exhaustive list of possible AX200 subsystem product IDs. So just match them all. Problem reported by Bobby Reynolds.
* Add support for AX201 devices to iwx(4).stsp2020-08-011-28/+141
| | | | | | | | | | Matching firmware can be installed with fw_update(1). Align our device initialization sequence more closely to how Linux does it. We still use a different MSI-X configuration but register values written up to that point are now identical. patrick@ provided help with debugging several issues along way, thanks!
* Enable background scanning on iwx(4) devices.stsp2020-07-131-4/+1
|
* Increase iwx(4) command queue size to the size expected by hardware.stsp2020-07-131-26/+11
| | | | | | | | | | | | | | | | | | | | The iwx(4) command queue has 256 entries in hardware. The Linux driver contains an abstraction layer which allows it to allocate just 32 command queue entries in software. Because I misunderstood how this works iwx(4) ended up with 32 command queue entries, but without a shim which presents these 32 entries as 256 entries to hardware. Our command queue size was later bumped to 64 to make fatal firmware errors during initialization disappear. The problem was still not fully understood at that time. I didn't realize that firmware errors coincided with the command queue index wrapping around. Hardware expects the queue to wrap at 256 entries so fix this problem for good in a simple way: Allocate 256 entries for the command queue, just like iwm(4) does. This will allow us to enable background scanning on iwx(4), which so far triggered firmware errors due to additional scan commands causing the command queue index to wrap at 64.
* Change users of IFQ_DEQUEUE(), IFQ_ENQUEUE() and IFQ_LEN() to use thepatrick2020-07-101-2/+2
| | | | | | "new" API. ok dlg@ tobhe@
* Switch iwx(4) from -46 to -48 firmware.stsp2020-07-071-2/+2
| | | | | The -48 firmware image has been available via fw_update(4) for about 4 weeks by now. It is contained in iwx-firmware-20191022p1.
* Remove AMRR/MiRA support from iwx(4). Tx rate selection happens in firmware.stsp2020-06-221-133/+12
|
* Remove unused code for parsing non-volatile memory (NVM) from iwx(4).stsp2020-06-221-336/+3
|
* Prepare for newer iwx(4) firmware scan command versions.stsp2020-06-221-4/+18
| | | | | | | | | Add declarations of "version 2" scan flags from iwlwifi and prepare the iwx_scan_channel_cfg_umac struct for life beyond version 1. None of this is needed yet. But we will need this at some point and I've already written the diff, hoping it would prevent firmware errors (which of course it didn't).
* Update definition of the iwx_ac_to_tx_fifo map.stsp2020-06-221-5/+5
| | | | | | Compared to iwm(4) devices the BE and BK fifo numbers have been swapped in iwx(4) hardware. This has no real consequences for us since we send all frames at the same access category, but I'm fixing the mapping anyway.
* Enable critical temperature detection in iwx(4) firmware.stsp2020-06-221-1/+45
| | | | | | The driver will turn the device off and print a message to dmesg if the firmware signals critical temperature. It looks like the firmware will also make use of a Tx-backoff mechanism to regulate device temperature.
* Do not copy an SSID into the iwx(4) probe request template.stsp2020-06-221-2/+4
| | | | | | | | Firmware will add SSIDs specified via the scan command to its probe requests. There is no need to copy an SSID into the template. This code path is not used yet because active scanning mode is still disabled in this driver.
* Fix unconditional write to v1.scan_priority in iwx(4) scan command.stsp2020-06-221-2/+3
| | | | | | | | | | The data structure for the scan command contains a union which represents various versions of the scan command. The driver wrote to the scan_priority field in version 1 data regardless of the scan command version actually expected by firmware. Perform that write only for scan command version 1, as intended. Testing suggests that this prevents occasional firmware errors during scans.
* Fix length specification for 2GHz band IE data in iwx(4) probe requeststsp2020-06-221-2/+2
| | | | | | | | | template. This code path is not used yet because active scanning mode is still disabled in this driver. ok kn@
* Make iwx(4) reset Tx byte count table slots for frames that are done.stsp2020-06-191-5/+11
| | | | | | | | | | | This fixes a "fatal firmware error" at run-time. Thanks again to Sara Sharon who provided the hint that the error trace I was looking at indicated that the firmware was running into a problem while trying to flush its Tx queues, and that this could be related to the Tx byte count table not being maintained properly. Tested by sven falempin and myself.
* Add WPA2 (CCMP) crypto offload support to iwx(4).stsp2020-06-191-13/+182
| | | | | | | | | | | | | | | | | | | | | | | | Much thanks to Sara Sharon who helped me by providing hints about new firmware behaviour. Contrary to older iwn(4) and iwm(4) devices, key material is no longer part of the Tx command. Instead, firmware will encrypt outgoing traffic as soon as the station associated with a Tx queue has an encryption key configured. Each Tx queue is created with an associated station ID (which in our case is a constant and represents the AP) and a traffic identifier (TID). The driver was configuring data Tx queues with the "management TID". This magic TID value bypasses hardware encryption and resulted in plaintext frames being sent while received frames were decrypted as expected since the station had a key. This behaviour looked rather strange and was difficult for me to debug. The clues which Sara provided led to the solution: iwx(4) must configure data Tx queues with the "non-QOS TID" in order to allow for encryption in the firmware's data Tx path. The rest of the offload mechanism works as it did on iwn(4) and iwm(4). Tested by sven falempin and myself.
* Let iwx(4) firmware decide which Tx rate to use.stsp2020-06-171-6/+146
| | | | | | | | | | | | The firmware will notify the driver when it decides to change Tx rate. Based on those notifications the driver updates the value displayed by ifconfig. This is similar to how bwfm(4) and urtwn(4) handle this. Offloading Tx rate selection should allow us to eventually delete AMRR/MiRA support code from iwx(4). That code is disabled for now, not yet deleted. For now, the driver restricts firmware Tx rate selection to 11n/20MHz mode because that's what net80211 can support.
* In iwn(4), iwm(4), and iwx(4), don't set the interface's MAC address againstsp2020-06-111-3/+1
| | | | | | | while building a scan command for the firmware. This isn't the right place to set our address, which has already been set during driver initialization. ok mpi@ kettenis@
* Make iwx(4) update the Tx ring byte count table.stsp2020-06-111-8/+1
| | | | | | | | | With iwn(4) and iwm(4) this was only required for Tx aggregation, which we don't use yet in iwx(4). But it looks like iwx(4) firmware will run into fatal errors if we neglect to update this table. The Linux iwlwifi driver always updates this table so firmware could be relying on it. Tested by jcs@, sven falempin, and myself.
* Load iwx(4) firmware just once.stsp2020-06-111-15/+1
| | | | | | | | | | | | | On iwx(4) devices there is no two-step firmware loading process with an INIT and RT image, as was the case with iwn(4) and iwm(4). Loading the image twice leaves firmware in a semi-operational state with problems such as fatal firmware errors and missing regulatory domain update notifications. Tested by jcs@, sven falempin, and myself. ok patrick@
* Add initial support for regulatory domain updates in iwx(4).stsp2020-06-111-7/+64
| | | | | | | | | | | | iwx(4) devices have a hardware component (the "communications hub") that can detect which country it is running in. The firmware will then inform the driver about the auto-detected regulatory domain. For now, just print a message which shows the detected regulatory domain if 'ifconfig iwx0 debug' is enabled. It is up to the driver whether it wants to react to regulatory domain updates. Tested by jcs@, sven falempin, and myself.
* Use the NVM_GET_INFO command in iwx(4) instead of the manual NVM datastsp2020-06-111-23/+183
| | | | | | | | | parser inherited from iwm(4). The old parsing code is merely disabled for now and will be deleted later. Deleting the old code at the same time would result in a very untidy diff. Tested by jcs@, sven falempin, and myself.
* Fix wrong size passed to free(9) when freeing an iwx(4) firmware image.stsp2020-06-101-51/+58
| | | | | | | Allocate the context info DMA region at attach time rather than when loading firwmare. Prevents this allocation from failing due to memory fragmentation. Tested by sven falempin and myself.
* Compute the Tx queue ID consistently in iwx(4).stsp2020-06-101-4/+4
| | | | | | | | | | | iwx_alloc_tx_ring() and iwx_tx() used different constants when computing the Tx queue ID. Make them use the same. Fortunately, this bug was harmless since we ended up using Tx queue 5 in both places. It would have broken badly as soon as we started using multiple Tx queues. ok mpi@
* fix wrong firmware filename typo in a comment in iwx_read_firmware()stsp2020-05-261-2/+2
|
* Make the necessary adjustments to parse iwx(4) -48 firmware image files.stsp2020-05-261-1/+9
| | | | | | This does not switch to newer firmware yet. The driver currently fails to send frames when -48 firmware is used. And the -48 firmware image is not yet available in fw_update(1).
* Implement support for the iwx(4) SOC_CONFIGURATION command.stsp2020-05-261-3/+50
| | | | | | | | This command doesn't seem to be needed with the ax200 device we currently support. But it does not hurt and will be needed for other devices this driver intends to support in the future. ok mpi@
* Don't enable any BT modules in the iwx(4) BT_COEX command.stsp2020-05-261-2/+2
| | | | | | | | | The iwx(4) driver intends to disable bluetooth. The command we sent to the firmware says "wifi only", but also enabled a bluetooth module. This seems to work as intended but is ambiguous. Linux also leaves all modules disabled in wifi-only mode. So do not enable any BT modules in the BT_COEX command. ok mpi@
* Make iwx(4) flush the Tx path before removing the AP from the firmware'sstsp2020-05-261-8/+7
| | | | | | station table. The Tx flush operation depends on the station being present. Avoids a fatal firmware error when the driver moves out of AUTH state.
* Make iwx(4) binding command work on -48 firmware.stsp2020-05-261-2/+3
| | | | | | | | Some firmware versions don't expect LMAC_5G_INDEX in the binding command. Set that value under the same conditions as the Linux driver does, which makes this command work on -48 firmware. ok mpi@
* Support iwx(4) firmware's BEACON_FILTER_CONFIG_API_S_VER_4 command.stsp2020-05-261-2/+10
| | | | | | | | Newer iwx(4) firmware versions will require a larger beacon filter command. The extra fields fields are initialized to zero even on Linux but newer firmware will require a size change anyway. ok mpi@
* Fix PHY_CONTEXT commands sent to iwx(4) firmware.stsp2020-05-161-54/+59
| | | | | | | | | | | | | | | | | | iwx(4) firmware understands two different variants of these commands. Both variants are documented with the same command API version number, but they use different sizes for an embedded struct which contains information about channels. Which variant to use depends on whether the firmware advertises support for the "ULTRA_HB_CHANNELS" feature. The code I wrote to handle both cases had a bug in case this feature is not supported: The channel info size difference was only accounted for while computing the command's length, but not while writing command data. This bug does not affect devices presently matched by iwx(4). But it is possible that other devices may need this fix in the future. So, for now, fix the buggy code path instead of removing it. ok mpi@
* Add the 'nomimo' nwflag which disables MIMO in 11n mode.stsp2020-04-291-4/+18
| | | | | | | | | This flag restricts a wireless driver to MCS0 - MCS7 for both transmission and reception. It can be set to work around packet loss in 11n mode caused by unused antenna connectors on a MIMO-capable wireless network device. man page tweak from tracey@ ok deraadt@
* Fix an automatic Tx rate control issue in iwm(4) and iwx(4).stsp2020-04-031-14/+20
| | | | | | | | | | | | | | | During a transmit burst, e.g. while tcpbench is running, iwm and iwx will queue up to 224 frames on the Tx ring. Rate control will make decisions a lot more often than just every 224 frames. Which means that results were reported and evaluated even if they did not correspond to the most recently chosen rate, spoiling the data available to the rate control algorithm. Prevent this problem by only reporting frames which match the currently chosen Tx rate. ok mpi@
* Remove 'done' flag from struct iwx_tx_data. Check data->m == NULL instead.stsp2020-04-021-7/+3
| | | | No functional change.
* When using a fixed Tx MCS in iwx(4) enable SGI if the peer supports it.stsp2020-03-311-1/+3
| | | | | This fix is needed for benchmarking MiRa against a fixed Tx rate, since MiRA will also use SGI if available.
* Fix bogus received frame data rates reported by iwx(4) in monitor mode.stsp2020-02-291-2/+2
|
* Let iwx(4) ignore RX_NO_DATA_NOTIF firmware messages; seen in monitor modestsp2020-02-281-1/+4
|
* In iwx(4) do not drop short control frames in monitor mode and do notstsp2020-02-281-2/+10
| | | | include the CRC trailer in the minimum length check for regular frames.
* In iwx(4), free mbufs that won't be passed to if_inputm().stsp2020-02-281-2/+8
|
* Sync monitor mode fixes from iwm(4) to iwx(4):stsp2020-02-281-6/+22
| | | | | | | | - use a distinct station ID for monitor STA - set station type to "general purpose" instead of "link" - use "any address" (zero) as station address instead of broadcast address - use the inject monitor Tx queue - accept multicast frames
* Sync tobhe's periodic interrupt fix from iwm(4) to iwx(4).stsp2020-02-281-19/+23
| | | | | | | | | | | Rx interrupt handling can lead to a race where the interrupt is handled before the shared data was updated. As a workaround each "real" interrupt enables the "periodic" Rx interrupt which triggers after 8 ms and detects any dangling Rx activity. If dangling Rx activity was detected the periodic interrupt is restarted, if not it stays disabled until the next "real" Rx interrupt is handled. The periodic interrupt is not supposed to write IWX_CSR_FH_INT_STATUS unless it has detected dangling Rx activity.
* Add iwx(4), a new driver for Intel AX200 wifi devices.stsp2020-02-151-0/+7899
The iwx(4) driver is based on code from iwm(4) and Linux iwlwifi. We are using a separate driver for this hardware family to avoid introducing even more complexity to iwm(4). Firmware loading and the Tx machinery in particular work differently compared to iwm(4) devices. Device firmware can be installed with fw_update(8). These devices support Tx rate scaling and Tx aggregation in firmware but we leave this disabled for now and adapt the Tx rate with MiRa/AMRR instead. Active scans (scans with probe requests) and background scans don't work yet. Otherwise this driver has the same feature set as iwm(4).
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.