aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/iwx
Commit message (Collapse)AuthorAgeFilesLines
* iwx: clean up / document noise floor and RSSI fetchingAdrian Chadd2026-05-192-11/+89
| | | | | | | | | | | | | | | | | | | | | * Document what iwx_rxmq_get_signal_strength() is doing in a comment, noting what the firmware returns and what math is being done on it to turn it into a dBm value. * Document what iwx_get_noise() is supposed to do, that we can't just go do math with log numbers like we're doing, but also that we're seeing zeros in this firmware (AX210), which may mean we're decoding using the wrong structs. * Swizzle around the RSSI calculation as a function, add min/max RSSI values, and calculate RSSI against the noise floor. * And handle the lowest noise floor value - it can't be -127dBm as that will throw things off. Cap it at -100dBm which is a little lower than the thermal noise floor at 20MHz (-98dBm), but it matches IWX_MIN_DBM. Differential Revision: https://reviews.freebsd.org/D53780
* iwx: Re-activate the 32-bit boundary cross check on 64-bit architecturesOlivier Certner2026-03-061-3/+3
| | | | | | | | | | __SIZEOF_*__ is in bytes, not in bits... Reported by: brooks Fixes: 35da55c28dbb ("iwx: Fix 32-bit compilation") MFC after: 1 minute MFC to: stable/15 Sponsored by: The FreeBSD Foundation
* iwx: Fix 32-bit compilationOlivier Certner2026-03-051-6/+17
| | | | | | | | | | | | | | - Avoid shifts wider than integer types, by wrapping the corresponding checks into '#if __SIZEOF_SIZE_T__ > 32' blocks. 'bus_addr_t' currently has the same width as 'size_t' on all architectures (and this is not going to change for 32-bit architectures). - Use appropriate printf(3) format for 'wk_keytsc'. Reviewed by: adrian MFC after: 1 minute MFC to: stable/15 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D55667
* iwx: migrate to new net80211 encryption key APIAdrian Chadd2026-02-111-4/+6
| | | | | | | | | | | Migrate to the new encryption key API rather than poking at the key struct directly. Locally tested: * STA mode - iwx0: <Wi-Fi 6 AX210> mem 0x84c00000-0x84c03fff at device 0.0 on pci4 Differential Revision: https://reviews.freebsd.org/D54463
* iwx: tag RX frames as A_MPDU RX; tag A-MSDU frames appropriatelyAdrian Chadd2025-11-211-30/+32
| | | | | | | | | | | | | | | | | | | | | | | * tag packets for 11n/11ac associated nodes with A_MPDU so they get passed into the reordering logic * tag A-MSDU frames with AMSDU and AMSDU_MORE so they don't get dropped due to duplicate sequence numbers. Note: I haven't yet elicited A-MSDU in A-MPDU to fully test this, but I do see the net80211 reordering logic kick in (which you can see via wlanstats -i wlan0 -o ampdu 1). I've checked with Johannes Berg at Intel (who maintains the linux iwlwifi stuff); he replied saying none of the firmware versions are doing AMPDU reorder offloading. Differential Revision: https://reviews.freebsd.org/D53781 Locally tested: * AX210, STA mode, > 200mbit bidirectional traffic testing on 5GHz VHT/40.
* iwx: clean up TX AMPDU session establishment and checkingAdrian Chadd2025-11-143-28/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | * Send a TX A-MPDU exchange successfully; we were allocating the A-MPDU TX queue but returning 0 to net80211 was telling it to not establish the TX A-MPDU session and none of the BA session tracking stuff would work. * Clean up the TX A-MPDU queue lookup in the transmit path - only QoS data frames are allowed, not qos null-data, cf/ack/etc frames; only send them if the A-MPDU session is established. * Tell net80211 that we've established the TX A-MPDU session once the firmware queue has been created. * Check to make sure we're not double (or more) creating TX AMDPU sessions - only allocate a qid if we're not doing A-MPDU yet. * Delete IWX_FLAG_A-MPDUTX - it's now being properly tracked! Locally tested: * AX210, STA mode - gets 50/50mbit on 2GHz HT20, and 100/100mbit on 5GHz VHT/40. Differential Revision: https://reviews.freebsd.org/D53725 Reviewed by: thj
* iwx: fix and clean up suspend/resume pathAdrian Chadd2025-11-141-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed a couple of things were happening: * during suspend, I'd get a timeout in the NIC lock path (which sets a bit on the NIC to say that the host wants to talk to it); * resume wouldn't come back - scan commands would fail, and you'd have to reinit the NIC again for it to work. The thing is: * the suspend path should already shut down the NIC by shutting down all the VAPs (and the last VAP should call ic_parent to bring it down), and * the resume path should already bring up the NIC by bringing up each VAP, and the first VAP to be brought up calls ic_parent to bring it up. So instead, I've shuffled around the code to just double check the hardware state is consistent /before/ ieee80211_suspend_all() and ieee80211_resume_all() is called. This both fixes the errant hardware timeout during suspend, and it fixes resume to work. Locally tested: * AX210, STA mode, both hardware ACPI suspend/resume and devctl suspend and devctl resume Differential Revision: https://reviews.freebsd.org/D53721 Reviewed by: thj
* iwx: clean up debugging around key add/set; comments on deleteAdrian Chadd2025-11-142-15/+26
| | | | | | | | | | * Add IWN_DEBUG_KEYMGMT as a debug flag * Convert DPRINTF(()) in key add/set to IWN_DPRINTF() * printf() -> net80211_vap_printf() * add braces around return value Differential Revision: https://reviews.freebsd.org/D53703 Reviewed by: thj
* iwx: migrate to using net80211 crypto key methodsAdrian Chadd2025-11-111-25/+23
| | | | | | | | | | | | | In preparation for further MFP key work, migrate iwx away from using IEEE80211_KEY_GROUP and pointer arithmetic. This is a hold over from ye olde days. Locally tested: * (STA mode, CCMP/CCMP network) * iwx0: <Wi-Fi 6 AX210> mem 0x84c00000-0x84c03fff at device 0.0 on pci4 Differential Revision: https://reviews.freebsd.org/D52523
* iwx: rewrite iwx_rs_update() to be VHT aware, refactor it a bitAdrian Chadd2025-10-042-76/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current iwx_rs_update() code doesn't handle setting VHT rates at all. So: * write a routine - iwx_rs_update_node_txrate() - which will update the given node txrate info with the given notification * .. which is based on the print_ratenflags() logic and decoding * migrate iwx_rs_update() to use this routine, only on the STA BSS node. This only handles decoding the version 2 rate_n_flags format response - same as print_ratenflags() - so print if someone somehow sees a version 1 response. It's shown a few things that deserve some later follow-up work: * I really should have net80211 APIs that operate on the txrate struct itself, not on the ieee80211_node, but I'll use what I have. Changing it later is easy. * the current net80211 txrate API doesn't include channel width, LDPC/STBC and such. I didn't need it for the earlier tx rate representation migration, but it would be nice to add it. (The reason is that those choices are currently made in the drivers using rate control, rather than the rate control module, which is again what the older code did as well.) This means that the displayed rate isn't EXACTLY what the NIC has chosen - eg the NIC could quite happily decide to transmit a 20MHz or 40MHz frame to an 80MHz STA if that actually works out better. So just add TODOs for those. Locally tested: * AX210, STA mode Differential Revision: https://reviews.freebsd.org/D52767 Reviewed by: thj
* iwx: don't log VHT rate lookups in iwx_tx_fill_cmd() for data framesAdrian Chadd2025-10-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | iwx is now logging a lot of stuff to the kernel when associated at VHT rates. It's my fault; the replacement tx rate APIs print out a warning when you're handing the legacy rate /HT rate APIs a VHT rate. However all of the supported chipsets in iwx will be pushing the rate control entirely into firmware. We don't need to do per-frame TX rate control like in previous chips. So for now, just put in an if (rate == VHT) into the path and a TODO comment. A few lines later the function will just skip the rate assignment stuff for data frames, thus saving us the logging. The other paths (control traffic, multicast traffic) uses legacy rates / HT rates by default and won't trigger a warning log. Yes, iwx_tx_fill_cmd() really does deserve a rate control logic rewrite, but I want to fix this particular issue first. Locally tested: * AX210, STA mode, HT and VHT associations Differential Revision: https://reviews.freebsd.org/D52766 Reviewed by: thj
* iwx: add some lock assertions in the TX start pathAdrian Chadd2025-10-041-0/+6
| | | | | | | | | The locking paths into these routines LOOK correct, but I figured it'd be good to at least enforce we're not doing concurrent entry into iwx_start() / iwx_tx() without the lock held. Differential Revision: https://reviews.freebsd.org/D52655 Reviewed by: thj
* iwx: add some missed beacon debuggingAdrian Chadd2025-10-041-4/+12
| | | | | | | | | I'm seeing random disconnects in iwx without any useful information as to why. I'll start by adding missed beacon debugging here; hopefully they're generally useful. Differential Revision: https://reviews.freebsd.org/D52524 Reviewed by: bz
* iwx: re-add sequence numbers for non-AMPDU, preserving previous behaviourAdrian Chadd2025-09-211-2/+3
| | | | | | | | | | | | | | | | | | | | I received a report on freebsd-wireless@ that traffic stopped working. It seems that although my AX210 is fine with this change, the AX201/22000 hardware/firmware seems to require it. There's a bit to set in the TX command to force the FW to set the sequence control. We only set a few flags, and we don't set that. So, add the sequence number allocation where encryption is performed. Locally tested: * AX210, STA mode * AX201, STA mode Differential Revision: https://reviews.freebsd.org/D52652 Reviewed by: kevans Tested by: kevans
* [iwx] tell net80211 not to originate NULL data framesAdrian Chadd2025-09-201-0/+2
| | | | | | | | | | | Tell it not to originate NULL / QoS NULL data frames. The firmware will handle them here. Differential Revision: https://reviews.freebsd.org/D52300 Reviewed by: bz Locally tested: * 9260, STA mode
* iwx: enable seqno offloadAdrian Chadd2025-08-241-0/+7
| | | | | | | | | | Enable sequence number offload. This should both enable the sequence number offloading and disable the net80211 TX lock from being acquired/released/checked. Reviewed by: bz, thj Differential Revision: https://reviews.freebsd.org/D50694
* iwx: correct rx status reportingBjoern A. Zeeb2025-06-191-1/+0
| | | | | | | | | | We are currently not reporting any per-chain S:N values so remove IEEE80211_R_C_RSSI and IEEE80211_R_RSSI along with it as it is set already in the line above. Sponsored by: The FreeBSD Foundation Reviewed by: thj Differential Revision: https://reviews.freebsd.org/D50927
* iwx: correct chain number reportingBjoern A. Zeeb2025-06-191-1/+16
| | | | | | | | | | | There is no point in assigning the channel index to the number of chains for the RX status reporting. The value was not tagged as being used. Rather than simply removing it try to fix it and set the flag if we get a value. Sposnored by: The FreeBSD Foundation Reviewed by: thj Differential Revision: https://reviews.freebsd.org/D50926
* if_iwx: use net80211 suspend and resume methodsTom Jones2025-05-281-7/+17
| | | | | | | | | | | | | Use net80211 suspend and resume methods when entering and leaving suspend. Move the resume action outside of the IWX_LOCK. Re-assert disabling the PCI timeout, this is copied from OpenBSD (and a common pattern), but it doesn't seem to hurt. PR: 286059 Reviewed by: adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D50462
* if_iwx: Make firmware load error messages clearerTom Jones2025-05-281-3/+4
| | | | | | | | | | | | | | Try to make it clearer where the errors are coming from in the iwx firmware load path. In particular make it clearer that transferring firmware to the card failed, not the loading of firmware. Hide the init firmware failed message behind a debug level, there are other errors which will show already in this path and for most people this doesn't add much. Reviewed by: adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49826
* iwx: Remove debug logging codeTom Jones2025-04-143-346/+177
| | | | | | | | | | | | | | | This debugging code was added this log as part of an effort to diagnose firmware crashes in an earlier version of the driver. It hasn't been used for a while and I'm not sure how useful it is for this compared to other methods. While reorganisation move strings for print mappings into if_iwx_debug.c to reduce their scope. Suggested by: bz Reviewed by: bz Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49783
* iwx: Use subdevice for comparisonTom Jones2025-04-141-3/+2
| | | | | | | | | | | | | | | iwx goes through a couple of steps to match devices to firmware. There is a default match of pcie device and subdevices and then a secondary pass to find a template configuration struct. Previously we were looking up the device not the subdevice and that led to ax210 cards in some devices (Framework 13) from being matched to the correct firmware. PR: 285905 Reviewed by: bz, adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49759
* iwx: Shorten log code fieldTom Jones2025-04-032-7/+7
| | | | | | | | | | | The widest value used with code is 32 bits, other values are smaller. Reduce this down. Update printfs. This fixes the build on i386. Reviewed by: bapt, emast, kevans, adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49634
* Import iwx as ported from OpenBSD by Future Crew.Tom Jones2025-03-315-0/+20448
This driver originates from OpenBSD and was ported to FreeBSD by Future Crew LLC who kindly provided a source release. iwx supports many recent Intel WiFi card and this driver should support running these cards with legacy, HT and VHT rates. There are some issues remaining in the port, but at this point wider testing is sought. To avoid breaking deployed WiFi configurations iwx probes with a lower priority than iwlwifi. This can be changed by blocking iwlwifi with devmatch. Reviewed by: adrian Obtained from: Future Crew LLC Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49259
generated by cgit v1.3 (git 2.53.0) at 2026-08-28 04:04:42 +0000