Fix clang warning about possible unaligned access on arm64.

ok stsp@

Add initial 802.11ac support to the iwm(4) driver.

VHT MCS and 80MHz channels can now be used.
Other 11ac features such as larger aggregates are left for later work.

Tested:
3160: stsp
7260: floria

Add initial 802.11ac support to the iwm(4) driver.

VHT MCS and 80MHz channels can now be used.
Other 11ac features such as larger aggregates are left for later work.

Tested:
3160: stsp
7260: florian, jmatthew
7265: rfreeman, mlarkin, landry, Peter J. Philip
8260: bket
8265: jturner, Marcus MERIGHI, stsp
9260: florian, matthieu, stsp
9650: kmos, sthen

ok sthen@

show more ...

spelling
feedback and ok tb@ jmc@ ok ratchov@

Make iwm(4) attach to PCI devices with product ID 0x31dc.

This device is part of the 9560 chip family. With a small device-specific
quirk we can make iwm(4) attach and provide a working wifi interfa

Make iwm(4) attach to PCI devices with product ID 0x31dc.

This device is part of the 9560 chip family. With a small device-specific
quirk we can make iwm(4) attach and provide a working wifi interface.

Problem reported and fix tested by Joao Victor.

show more ...

Add support for 802.11n 40MHz channels to the iwm(4) driver.

According to 11n MCS index tables our maximum data rate is now
300 Mbit/s at MCS 15, excluding protocol overhead. I have measured
up to 2

Add support for 802.11n 40MHz channels to the iwm(4) driver.

According to 11n MCS index tables our maximum data rate is now
300 Mbit/s at MCS 15, excluding protocol overhead. I have measured
up to 200Mbit/s of effective throughput on clean 5GHz channels.

The driver enables use of 40MHz channels automatically as long as the
access point announces support for such channels in its beacons.
In case 40MHz transmissions fail we ask firmware to retry with a
20MHz transmission.

There is no integration with ifconfig yet, so use of 40MHz is not yet
displayed there. In the meantime, tcpdump(8) can be used to check if
the current access point supports 40MHz:
tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype beacon
Channel width is displayed in the HT operation information element, where
a 40MHz channels looks like this: htop=<40MHz chan X:Y ...>

Tested:
7260: florian, bcallah
7265: landry
8260: bket
8265: stsp, abieber, Matthias Schmidt, Josh Rickmar, empee on mastodon
9560: stsp

show more ...

Make iwm(4) set various scan command flags just like how iwlwifi sets them.
Discrepancies found while investigating an issue related to active scanning.

Support MCC update response used by newer iwm(4) firmware, and verify
the size of the response we receive for MCC_UPDATE commands (even
though we aren't doing anything with this response yet).

With

Support MCC update response used by newer iwm(4) firmware, and verify
the size of the response we receive for MCC_UPDATE commands (even
though we aren't doing anything with this response yet).

With the correct expected response length this time. The driver needs
to expect the maximum response size, not sizeof() the response struct.
The actual response size depends on the number of channels stored
in the "world" regulatory profile of the device.

ok sthen@

show more ...

Back out support for newer MCC update commands in iwm(4) for now.
This seems to cause "could not init LAR" errors on some devices.

Reported by dv@ (8265) and sthen@ (9560)

Support MCC update response used by newer iwm(4) firmware, and verify
the size of the response we receive for MCC_UPDATE commands (even
though we aren't doing anything with this response yet).

Support the SoC configuration command used by newer iwm(4) 9560 firmware.

Support the critical temperature detection feature of newer iwm(4) firmware.

Parse CMD_VERSION TLV found in iwm(4) fw images and add iwm_lookup_cmd_ver().

It seems Intel saw a risk of eventually running out of firmware capability
support and API support flags, so yet another

Parse CMD_VERSION TLV found in iwm(4) fw images and add iwm_lookup_cmd_ver().

It seems Intel saw a risk of eventually running out of firmware capability
support and API support flags, so yet another such mechanism was added.
If you want to know which variant of a command needs to be used there are
now at least three places to check for related information.

show more ...

Support a new variant of the binding command required by new iwm(4) firmware.

Support the larger phy context command required by newer iwm(4) firmware.

Recognize and ignore new debug sections found in latest iwm(4) 9k fw images.

Support a new time quota command required for newer iwm(4) firmware.

Fix Tx queue flushing in iwm(4).

iwm(4) was still using an outdated version of the TX_FLUSH command.
Current firmware expects a different version which has the same size but
different semantics. The

Fix Tx queue flushing in iwm(4).

iwm(4) was still using an outdated version of the TX_FLUSH command.
Current firmware expects a different version which has the same size but
different semantics. The iwx(4) driver is already using the new version.

Also do not log errors if flushing Tx queues fails. This can happen if
the AP disappeared. Just cope by resetting the device and clearing rings.

Should fix "flushing Tx queues failed" and related firmware errors.

show more ...

Revert iwm(4) firmware updates for now; robert@ reports stalled Tx on 9260

Switch iwm(4) to new firmware images available in iwm-firmware-20210512.

This updates firmware for 3165, 3168, 7265, 8260, 8265, 9260, 9560 devices.
Other devices did not receive firmware updates fr

Switch iwm(4) to new firmware images available in iwm-firmware-20210512.

This updates firmware for 3165, 3168, 7265, 8260, 8265, 9260, 9560 devices.
Other devices did not receive firmware updates from Intel.
New firmware images should contain revelant fixes for fragattacks:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html

Running fw_update(1) may be required before rebooting into a new kernel.
sysupgrade(8) will take care of this.

When reporting issues (I am sure there will be new "fatal firmware errors"
for some people) please enable 'ifconfig iwm0 debug', reproduce the error
once more, and include the full dmesg in your bug report.

Important changes required for new firmware:
- Support new variants of several existing firmware commands just
because Intel loves adding new features and changing the commands.
- Implement the 'clear persistence bit' workaround for 9k devices to
avoid potential issues during suspend/resume.
- Recognize Mobile Country Code update notifications for the regulatory
domain, like iwx(4) does.
- Handle PHY context updates more like the Linux iwlwifi driver does.
Some devices need an add/remove dance if the band has changed.
- For 9560, configure SoC latency parameters after booting firmware.
- Handle critical temperature notifications by shutting the device down.
- Use only antenna B for single-antenna Tx on 9k devices (matches what
Linux and FreeBSD do; Likely only matters if Bluetooth is active, but
who knows, Git logs and comments are the only documentation we have).

Other small fixes:
- Fix various scan command parameters. Some fixes were taken from iwx(4).
- Don't send probe requests when scanning passive channels. Experimentation
has shown that this will make 9k devices crash after associating to an AP.
This same fix does not seem to work on iwx(4) devices, where active scan
is disabled for the same reason, and it is not yet clear why.
- Fix firmware reloading after parsing the firmware image has failed.
- Flushing Tx rings will fail if the AP disappears. Don't make any noise
about that in dmesg, instead gracefully reset the device and continue.

Tested:
7260: florian
3168: kevlo
7265: stsp, mlarkin
8260: bket
8265: stsp, benno
9560: stsp, steven

show more ...

Add 802.11n Tx aggregation support to iwm(4).

Makes packets go swoosh swoosh swoosh. Welcome to actual 802.11n!

Tested:
7260: dv, florian
7265: trondd, dv, landry, stsp
8260: bket
8265: Matthias Sc

Add 802.11n Tx aggregation support to iwm(4).

Makes packets go swoosh swoosh swoosh. Welcome to actual 802.11n!

Tested:
7260: dv, florian
7265: trondd, dv, landry, stsp
8260: bket
8265: Matthias Schmidt, stsp
9260: kettenis
9560: phessler, stsp

show more ...

Implement support for Rx aggregation offload in iwm(9) and iwx(4), and
re-enable de-aggregation of A-MSDUs in net80211 for all drivers capable
of 11n mode. This can provide improved Rx performance if

Implement support for Rx aggregation offload in iwm(9) and iwx(4), and
re-enable de-aggregation of A-MSDUs in net80211 for all drivers capable
of 11n mode. This can provide improved Rx performance if the access point
supports transmission of A-MSDUs nested in A-MDPUs.

iwm(9) 9k and iwx(4) devices de-aggregate A-MSDUs in hardware.
Neither our drivers nor the net80211 stack were prepared to handle this.

Add two Rx-info flags which drivers can use to avoid having subframes which
arrived in the same A-MSDU rejected as duplicates in the net80211 input layer:
IEEE80211_RXI_HWDEC_SAME_PN allows the same CCMP packet number for a series
of subsequent frames. IEEE80211_RXI_SAME_SEQ allows the same 802.11 frame
header sequence number for a series of subsequent of frames.

Handle A-MPDU reordering on iwm 9k and iwx devices, based on code from iwlwifi.
Rx block ack window information is provided by firmware. So far this info was
ignored by drivers and reordering of A-MPDU subframes happened twice: Once in
firmware, and again in net80211.

Tested:
iwm 7260: bcallah, dv
iwm 7265: mpi, trondd, Matthias Schmidt
iwm 8260: bket, Marcus MERIGHI
iwm 8265: stsp, tracey, Uwe Werler
iwm 9260: phessler, matthieu
iwm 9560: stsp, Uwe Werler
iwx ax200: jmc, stsp
iwx ax201: stsp

show more ...

Offload CCMP (WPA2) encryption and decryption to iwm(4) hardware.

This reduces CPU load during traffic bursts.
Based on an older diff we had in CVS history, updated to work with
newer firmware versi

Offload CCMP (WPA2) encryption and decryption to iwm(4) hardware.

This reduces CPU load during traffic bursts.
Based on an older diff we had in CVS history, updated to work with
newer firmware versions we use today.

Tested on the following devices, with great support from several people:
3160 (stsp)
3168 (stsp)
7260 (jmatthew, tobhe)
7265 (stsp, procter, gonzalo)
8265 (benno, tb)
8260 (stsp, Liberto on bsd.network)
9260 (stsp, Jesper Wallin)
9560 (stsp)

Not tested: 3165; these run the same firmware as 7265 so will likely be fine.
I couldn't find a 3165 device in my pile.

ok jmatthew@ (who also found a small bug in my diff)

show more ...

Fix wrong firmware API documentation comments for iwm(4) and iwx(4).
Both drivers currently use SCAN_CHANNEL_CFG_S_VER1, not VER2.

Update iwm(4) firmware API documentation with respect to sequence number
related fields in Tx commands and responses:

- IWM_AGG_TX_STATE_SEQ_NUM_MSK does not exist, remove it from documentation

- I

Update iwm(4) firmware API documentation with respect to sequence number
related fields in Tx commands and responses:

- IWM_AGG_TX_STATE_SEQ_NUM_MSK does not exist, remove it from documentation

- In our case, iwm_agg_tx_status's "sequence" field contains the Tx queue ID
and index of aggregated subframes, not sequence numbers. Update the struct
definition accordingly. (This struct is not used yet.)

- iwm_tx_resp and iwm_ba_notif contain frame header sequence control fields.
Be explicit about this in documentation.
I don't understand which frame the sequence control field in iwm_ba_notif
corresponds to. Leave a comment about that. iwlwifi doesn't use this field.

show more ...

Add support for MSI-X. MSI-X allows establishing a number of
interrupt vectors and mapping events (RX on queues, commands,
mgmt frames) to those vectors. For now we keep the existing
behaviour, est

Add support for MSI-X. MSI-X allows establishing a number of
interrupt vectors and mapping events (RX on queues, commands,
mgmt frames) to those vectors. For now we keep the existing
behaviour, establish a single vector and map all events to it.

Makes my Intel NUC 8i5BEH 9560 work
Tested by jcs@ on a 9560 (w/ MSI-X)
Tested by deraadt@ on a 9260 (w/ MSI-X)
Tested by phessler@ on a 8260 (w/o MSI-X)
ok stsp@

show more ...