iwx: tag RX frames as A_MPDU RX; tag A-MSDU frames appropriately

* tag packets for 11n/11ac associated nodes with A_MPDU so they
get passed into the reordering logic

* tag A-MSDU frames with AMSD

iwx: tag RX frames as A_MPDU RX; tag A-MSDU frames appropriately

* 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.

show more ...

iwx: clean up TX AMPDU session establishment and checking

* 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 estab

iwx: clean up TX AMPDU session establishment and checking

* 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

show more ...

iwx: fix and clean up suspend/resume path

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 w

iwx: fix and clean up suspend/resume path

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

show more ...

iwx: clean up debugging around key add/set; comments on delete

* Add IWN_DEBUG_KEYMGMT as a debug flag
* Convert DPRINTF(()) in key add/set to IWN_DPRINTF()
* printf() -> net80211_vap_printf()
* add

iwx: clean up debugging around key add/set; comments on delete

* 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

show more ...

iwx: migrate to using net80211 crypto key methods

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 d

iwx: migrate to using net80211 crypto key methods

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

show more ...

iwx: rewrite iwx_rs_update() to be VHT aware, refactor it a bit

The current iwx_rs_update() code doesn't handle setting VHT rates
at all.

So:

* write a routine - iwx_rs_update_node_txrate() - whic

iwx: rewrite iwx_rs_update() to be VHT aware, refactor it a bit

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

show more ...

iwx: don't log VHT rate lookups in iwx_tx_fill_cmd() for data frames

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

iwx: don't log VHT rate lookups in iwx_tx_fill_cmd() for data frames

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

show more ...

iwx: add some lock assertions in the TX start path

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: add some lock assertions in the TX start path

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

show more ...

iwx: add some missed beacon debugging

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 u

iwx: add some missed beacon debugging

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

show more ...