Add support for MA devices.

ok stsp@

remove duplicate IWX_NVM_GET_INFO define

fix iwx(4) monitor mode

Monitor mode was broken by a recent firmware update. Two tweaks make
it work again:

1) The firmware does not like us sending the power-mode command while
in monitor mode and

fix iwx(4) monitor mode

Monitor mode was broken by a recent firmware update. Two tweaks make
it work again:

1) The firmware does not like us sending the power-mode command while
in monitor mode and will panic, so simply don't do that.

2) We no longer add two queues while in monitor mode, just one queue
for frame injection. This queue's index will be 1, not 2. Make the
driver expect the correct index to prevent an error when monitor mode
is entered.

tested by jmc@ and myself on iwx ax200

show more ...

Ignore thermal dual-chain requests from iwx(4) firmware.

Linux only acts on these requests in 11ax mode on 160MHz channels so
we can simply ignore this request for now. Prevents a warning from
being

Ignore thermal dual-chain requests from iwx(4) firmware.

Linux only acts on these requests in 11ax mode on 160MHz channels so
we can simply ignore this request for now. Prevents a warning from
being printed when we receive such a request:
iwx0: unhandled firmware response 0x5f6/0x20000008 rx ring 64[3]

Observed on AX210 hardware by bluhm@

show more ...

support the new iwx SCD_QUEUE_CONFIG command

Required for adding/removing Tx queues on new firmware versions.

Semantics have changed yet again. Good old iwm(4) required manual
removal of related Tx

support the new iwx SCD_QUEUE_CONFIG command

Required for adding/removing Tx queues on new firmware versions.

Semantics have changed yet again. Good old iwm(4) required manual
removal of related Tx queues when a station is removed from firmware.
At some point iwx(4) firmware removed this requirement and demanded
that queue removal would be done implicitly by firmware instead.
And now the firmware engineers at Intel have again changed their
minds about this, and explicit queue removal is required again.
It is sad that we are being driven through such a marathon of changes
just in order to pick up some firmware security fixes...

show more ...

add support for the iwx BAID allocation config command

This command is required to set up Rx aggregation on new firmware.

implement support for iwx PHY context cmd version 4

support the new IWX_STA_MAC_DATA_API_S_VER_2 API

MAC context command fields which firmware has been ignoring since the iwm
hardware generation have been repurposed for information related to 11ax.
J

support the new IWX_STA_MAC_DATA_API_S_VER_2 API

MAC context command fields which firmware has been ignoring since the iwm
hardware generation have been repurposed for information related to 11ax.
Just set these fields to zero. Firmware -71 and up will panic otherwise.

show more ...

add support for the iwx RLC config command

New firmware wants to be told about MIMO antenna configuration via
a separate command, rather than via the good old PHY context command.

support iwx rate_n_flags API version 2 and delete fixed Tx rate support

As of this commit iwx will ignore 'ifconfig media' commands where the
user-specified Tx rate resolves to something other than

support iwx rate_n_flags API version 2 and delete fixed Tx rate support

As of this commit iwx will ignore 'ifconfig media' commands where the
user-specified Tx rate resolves to something other than 'autoselect'.
The existing support for forcing a Tx rate was already only partially
working in 11n and 11ac modes. I doubt anyone had a serious use case for
this. If you really need to force a specific Tx rate for data frames
sent by iwx then hack the driver instead of using 'ifconfig media'.

The firmware interface was designed for Tx rate selection in firmware.
Maintaining support for overriding the Tx rate with ifconfig in face of
complicated firmware interface changes such as this rate_n_flags change
is just not worth it. While trying to keep forced Tx rates working on top
of the new rate_n_flags format I accidentally broke the Tx rate used for
managment frames during regular operation, which caused much frustration.

show more ...

change current iwx rate_n_flag field names to indicate this is API version 1

also add some missing bits found in the Linux driver while here

add support for iwx TLC config command v4

add support for iwx firmware alive response version 6

recognize more iwx ucode TLV sections which are present in newer fw images

jca@ points out that the field I split in iwx(4) Rx descriptors is in a union.
Keep semantics of the field intact by wrapping the split values in struct { }.
Again no size change, because of union se

jca@ points out that the field I split in iwx(4) Rx descriptors is in a union.
Keep semantics of the field intact by wrapping the split values in struct { }.
Again no size change, because of union semantics.

diff from jca@ with request to commit if ok, thanks!
build-tested again + ok tb@

show more ...

Fix an alignment issue in iwx(4) Rx descriptors.

Split a 64-bit field, aligned at a 4-byte boundary, into two 32 bit fields.
Our driver does not use this field. Its definition does not matter to us,

Fix an alignment issue in iwx(4) Rx descriptors.

Split a 64-bit field, aligned at a 4-byte boundary, into two 32 bit fields.
Our driver does not use this field. Its definition does not matter to us,
as long as its size remains correct.

Fixes clang-15 warnings, which turn into compilation errors with -Werror.

Reported by, and ok tb@

Relevant clang 15 errors are:

In file included from /sys/dev/pci/if_iwx.c:151:
/sys/dev/pci/if_iwxreg.h:3659:2: error: field within 'struct iwx_rx_mpdu_desc_v1' is less aligned than 'union iwx_rx_mpdu_desc_v1::(anonymous at /sys/dev/pci/if_iwxreg.h:3659:2)' and is usually due to 'struct iwx_rx_mpdu_desc_v1' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
union {
^
/sys/dev/pci/if_iwxreg.h:3626:2: error: field within 'struct iwx_rx_mpdu_desc_v3' is less aligned than 'union iwx_rx_mpdu_desc_v3::(anonymous at /sys/dev/pci/if_iwxreg.h:3626:2)' and is usually due to 'struct iwx_rx_mpdu_desc_v3' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
union {
^
2 errors generated.

show more ...

Fix reading of the MAC address on AX210 devices.

wrong MAC address issue spotted by jsg@ and kevlo@
ok kevlo@

Add support for AX210/AX211 devices to iwx(4).

Firmware is available in fw_update(8) as of iwx-firmware-20220110.

Tested for regressions on AX200/AX201 by jmc, kettenis, and myself.

Tested on AX21

Add support for AX210/AX211 devices to iwx(4).

Firmware is available in fw_update(8) as of iwx-firmware-20220110.

Tested for regressions on AX200/AX201 by jmc, kettenis, and myself.

Tested on AX210 by abieber (framework laptop) and myself, both using
a device which loads ty-ao-gf-a0 firmware.
AX210/AX211 devices which load the following firmware files should
work but could not yet be tested due to lack of hardware:
iwx-so-a0-gf-a0-67, iwx-so-a0-gf4-a0-67, iwx-so-a0-jf-b0-64

show more ...

Make device matching in iwx(4) more similar to Linux iwlwifi.

There are a few chips which cannot be recognized by PCI ID alone.
Reading device registers is also required to identify such devices.

i

Make device matching in iwx(4) more similar to Linux iwlwifi.

There are a few chips which cannot be recognized by PCI ID alone.
Reading device registers is also required to identify such devices.

iwx(4) should now detect AX201 devices requiring the following firmware
images:

iwx-Qu-b0-hr-b0-63
iwx-Qu-b0-jf-b0-63
iwx-Qu-c0-jf-b0-63
iwx-QuZ-a0-hr-b0-67
iwx-QuZ-a0-jf-b0-63

These are already installed in /etc/firmware but have so far been unused.

This is obviously going to cover a range of devices which have not actually
been tested yet. If you have such a device please test and report back.
Tested on previously working AX200/AX201 devices by jmc@ and myself.
Sven Wolf has successfully tested a newly supported device.

Based on an initial patch by Iraklis Karagkiozoglou, thanks!

show more ...

Add initial support for 802.11ac (VHT) to the iwx(4) driver.

This makes it possible to use 80MHz channels and VHT-specific MCS.
Other 11ac features remain disabled for now.

Tested:
ax200: Matthias

Add initial support for 802.11ac (VHT) to the iwx(4) driver.

This makes it possible to use 80MHz channels and VHT-specific MCS.
Other 11ac features remain disabled for now.

Tested:
ax200: Matthias Schmidt, phessler, dv, kevlo, Joel Carnat, hrvoje, jmc, stsp
ax201: mlarkin, stsp
iwm (regression testing): stsp

show more ...

When it's the possessive of 'it', it's spelled "its", without the
apostrophe.

spelling
feedback and ok tb@ jmc@ ok ratchov@

Prepare iwx(4) for using new firmware (API version -67) in the future.

Bump command versions array size as required for -67 firmware.
Ignore new TLVs found in -67 images.
Add room for another ucode

Prepare iwx(4) for using new firmware (API version -67) in the future.

Bump command versions array size as required for -67 firmware.
Ignore new TLVs found in -67 images.
Add room for another ucode section needed for -67 on AX201 devices.

show more ...

Fix iwx(4) Tx ring array size which was one entry too short.

Fortunately, this bug was harmless. The last Tx agg queue is never used
because ieee80211_classify() only returns TID values in the range

Fix iwx(4) Tx ring array size which was one entry too short.

Fortunately, this bug was harmless. The last Tx agg queue is never used
because ieee80211_classify() only returns TID values in the range 0 - 3.
And iterations over the txq array use nitems() to find the upper bound.

The possiblity of shrinking the txq array by 4 elements to get rid of
unused Tx agg queues could be investigated later.
For now, just fix the off-by-one error.

ok kettenis@

show more ...

Add support for Tx aggregation to the iwx(4) driver.

Throughput goes up to 100 Mbit/s under ideal conditions.

This is mostly working and stable, however rare occasional hangs may occur
where the de

Add support for Tx aggregation to the iwx(4) driver.

Throughput goes up to 100 Mbit/s under ideal conditions.

This is mostly working and stable, however rare occasional hangs may occur
where the device stops giving us interrupts for reasons which are not yet
understood.
In such cases ifconfig down/up will recover the interface. Regardless, this
code seems to be stable enough for remaining issues to be resolved in-tree.
My working assumption is that the remaining issues were always present but
only trigger under increased load when firmware is driven with Tx agg enabled.

Feedback is welcome, especially if stability issues turn out to be worse than
expected! As usual, please enable "ifconfig iwx0 debug" when reporting issues.

Tests on ax200/ax201:
myself, dv, hrvoje, Stefan Hagen, kevlo, Eric Auge, mlarkin, jmc, Mark Patruck

Of which only me and jmc have reported seeing a small amount of hangs during
continuous usage over about 2 weeks.

show more ...