Introduce a local change. It seems ieee80211_get_tid() does not deal
with non-dataqos packets unlike net80211's ieee80211_gettid().
Gernally all calls in Linux drivers to ieee80211_get_tid() seem to
be proceeded by an ieee80211_is_data_qos() check.
Moving the ieee80211_get_tid() has no difference in the result, but
(a) saves us the call if we do not need it due to an earlier return,
and (b) allows us to put an assert into the LinuxKPI ieee80211_get_tid()
implementation to avoid accidentally returning random frame header data
in case of a missing earlier ieee80211_is_data_qos() check in (future/
other) drivers.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
"Invalid TXQ id" and "Queue <n> is stuck <x> <y>" are two errors seen
more commonly by FreeBSD users. Try to gather some extra data the
"easy way" adding more error logging for these situations in the hope
to find a clue or at least do more targetd debugging in the future.
Note that for one of the errors the Linux Intel driver has a TODO to
print register data. If that will show up in future versions of the
driver this may also help.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Update iwlwifi 22000 firmware to -73 and rebuilds for 9000/9260.
Update the driver to accept the newer version.
Firmware was obtained from linux-firmware at
150864a4d73e8c448eb1e2c68e65f07635fe1a66.
Sponsored by: The FreeBSD Foundation
MFC after: 23 days
Upgrade the argument of (*bss_info_changed) mac80211 ops function call
from 32 to 64 bit.
Add an extra argument to ieee80211_beacon_get_template().
Both changes are needed in order to keep other out-of-tree drivers in
synch and to move forward.
The driver changes were extracted from Linux wireless-testing
7b7090b4c6a906cc7c3e2a460335f705b93f4506 and
6e8912a503759bb8f1f01c5b761d0d45815fa6de.
Sponsored by: The FreBSD Foundation
MFC after: 1 week
QAT in-tree driver ported from out-of-tree release available
from 01.org.
The driver exposes complete cryptography and data compression
API in the kernel and integrates with Open Crypto Framework.
Details of supported operations, devices and usage can be found
in man and on 01.org.
Patch co-authored by: Krzysztof Zdziarski <krzysztofx.zdziarski@intel.com>
Patch co-authored by: Michal Jaraczewski <michalx.jaraczewski@intel.com>
Patch co-authored by: Michal Gulbicki <michalx.gulbicki@intel.com>
Patch co-authored by: Julian Grajkowski <julianx.grajkowski@intel.com>
Patch co-authored by: Piotr Kasierski <piotrx.kasierski@intel.com>
Patch co-authored by: Adam Czupryna <adamx.czupryna@intel.com>
Patch co-authored by: Konrad Zelazny <konradx.zelazny@intel.com>
Patch co-authored by: Katarzyna Rucinska <katarzynax.kargol@intel.com>
Patch co-authored by: Lukasz Kolodzinski <lukaszx.kolodzinski@intel.com>
Patch co-authored by: Zbigniew Jedlinski <zbigniewx.jedlinski@intel.com>
Reviewed by: markj, jhb (OCF integration)
Reviewed by: debdrup, pauamma (docs)
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D34632
A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be kept
around to provide opencrypto offload support for those chipsets.
Reviewed by: pauamma, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35817
After some discussion, for now, simply revert the change to split
the driver up into if_rtw88_core.ko and if_rtw88_pci.ko as we do
not have an if_rtw88.ko anymore. We do have code trying to
auto-load modules, e.g. ifconfig, based on if_xxx.ko.
We could, based on Makefile magic or further code, generate a
if_rtw88.ko module with proper dependencies and keep this but for
simplicity stay with the one slightly larger module for now.
Should code appear to do this "properly" we can revisit this once
USB support has landed.
Slightly update the module Makefile to keep the separation of files
between core and pci bits visible and maintainable for the future.
This reverts commit 0f7b9777f8.
This patch removes warnings messages like the following added in ACPICA
20220331:
ACPI Warning: Firmware issue: Excessive sleep time (0xxx ms > 10 ms)
in ACPI Control Method (20220331/exsystem-347)
Note the original author of this patch wants to back it out:
https://github.com/acpica/acpica/pull/780
Update rtw88 based on wireless-testing at
4e051428044d5c47cd2c81c3b154788efe07ee11 (tag: wt-2022-06-10).
This is in preparation to apply USB changes to work on these and
LinuxKPI for them over the next weeks, as well to debug a
reported issue, and possibly extract and upstream some local fixes.
MFC after: 3 days
Split the driver up into two modules (if_rtw88_pci.ko and rtw88_core.ko).
This is in preparation for the hopefully eventually upcoming USB support
using the same driver core.
Note: this changes the module name to load to if_rtw88_pci.ko instead of
if_rtw88.ko. If using devmatch(8) everything should stay the same as
the driver name (used for net.wlan.devices) stays rtw88. If using
kld_list in rc.conf or loader.conf you will need to adjust the name.
Update man page for this.
MFC after: 3 days
Based on manual inspection the skbs are not freed in those unlikely
cases, though all would give an error message so would have gone noticed
if happened.
While here fix a typo in one of these error messages.
MFC after: 3 days
It is unclear why this hasn't bothered anyone in months; I can only assume
optimization levels but it seems there were unresolved symbols in
iwlwifi after d9836fb4b9:
link_elf_obj: symbol iwl_mvm_send_roaming_forbidden_event undefined
Hide more of the currently unsupported (GPL-only) MEI (Management Engine)
code behind #ifdef to avoid this.
Reported by: dchagin
Tested by: dchagin
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Add a FreeBSD-specifc SYSCTL_PROC to dump the list of
PCI IDs / name / firmware-prefix which can be post-processed
for man pages (iwlwifi.4 and iwlwififw.4) or the wiki.
The output still yields duplicates depending on by what information
you need so one may wants to filter them out (try not to use sort/uniq).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Working on an update for rtw88 baed on wireless-testing I ran into
a build issue with struct ieee802211_sta. Some fields were factored
out into their own struct apparently preparing for MLO (Multi Link
Operation).
In order to be able to update one driver we have to adjust both
rtw88 and iwlwifi (and the ones still out-of-tree) now.
This is mostly a sed-replace job and no functional changes are
intended.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Import two changes from torvalds/linux.git at tag: v5.18-rc7:
b20bdd9cc9740ac1f2138adab25ddd51245c67be
iwlwifi: mvm: Don't fail if PPAG isn't supported
7635a1ad8d92dcc8247b53f949e37795154b5b6f
iwlwifi: iwl-dbg: Use del_timer_sync() before freeing
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Update to the latest iwlwifi firmware based on
linux-firmware at b19cbdca78ab2adfd210c91be15a22568e8b8cae
(tag: 20220509)
and update firmware module Makefiles accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Import code update from iwlwifi-next
at e89600ebeeb14d18c0b062837a84196f72542830.
This amongst other things removes the deprecated BCAST_FILTERING option,
which we had disabled before due to firmware issues.
Also prepares us for the next firmware update.
The "enable_ini" module option has become an integer with a
sysctl proc equivalent handler. Disable the module parameter changing
for the moment until we'll have working LinuxKPI support or implement
it as SYSCTL_PROC in FreeBSD directly.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The 'failed to write TX skb to HCI' error message is twice in the code.
Print the function name and along with the message and also the reported
error so it can possibly be helpful.
The 'failed to get tx report from firmware' was purposefully changed
away from debugging in the upstream Linux driver in
584dce175f0461d5d9d63952a1e7955678c91086 . Revert that decision and
extend the logging by the actual queue length so we get an idea how
sever the problem is (see PR for a report).
PR: 248235
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC: only to get the reminder for later
Firmware version 9.9.11 added support for hw_scan and is reportedly
causing more problems than 9.9.10 does. Until we get a chance to
test this out downgrade the firmware in order to help people testing
more.
Sponsored by: The FreeBSD Foundation
PR: 248235
MFC after: 2 days
X-MFC: just to get the reminder with the original commit
X-MFC with: 73d4ebea35
Import the most recent versions of the firmware images for the
rtw88 driver.
This is based on linux-firmware at 681281e49fb6778831370e5d94e6e1d97f0752d6.
The license of the firmware matches the previous rtwnfw(4) firmware
files (modulo a Copyright year) and you can find a copy in
sys/contrib/dev/rtw88fw/LICENCE.rtlwifi_firmware.txt.
Add build infrastructure to create the .ko files but do not yet hook
it up to the build until all parts are in the tree.
Approved by: core (imp)
MFC after: 2 weeks
Import rtw88 based on wireless-testing at
5d5d68bcff1f7ff27ba0b938a4df5849849b47e3 with adjustments for FreeBSD.
While our version of the driver has knowledge about the incapablity
of DMA above 4GB we do see errors if people have more than that
often already showing when laoding firmware.
The problem for that is currently believed to be outside this driver
so importing it anyway for now.
Given the lack of full license texts on non-local files this is
imported under the draft policy for handling SPDX files (D29226). [1]
Approved by: core (imp) [1]
MFC after: 2 weeks
Rather than having LinuxKPI return BUS_PROBE_DEFAULT, return
"one less" so that on conflict of IDs others would be preferred.
This means that iwm(4) will attach instead of iwlwifi(4) for the
chipsets iwm(4) supports and iwlwifi(4) only for the other--in iwm(4)
unsupported--chipsets. This is done so that we can enable auto-loading
of drivers but for the upcoming 13.1-Release people with working iwm(4)
will not yet be affected by iwlwifi(4).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Update to the latest firmware based on
linux-firmware at c53073d4e1485ac9f7cb065db466793c495aead7
and update firmware module Makefiles accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Add a string of the debug type to the output of the debug message so it
is easier to search for specific events in a trace with lots of debugging
on. While here remove superflous ().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Import new code from iwlwifi-next at cb0a1fb7fd86b0062692b5056ca8552906509512
(matching tag: iwlwifi-next-for-kalle-2022-02-18).
Also add files not previously imported because we are not yet compiling
them to ease updating and having them when needed.
This adds MEI (Management Engine) support upstream which we cannot import
(currently GPL-only) so we have stub functions for the missing bits.
This also reduces the diff to upstream. Changes submitted to avoid
problems with const and with void * arithmetics were merged.
In the module build Makefile disable CONFIG_IWLWIFI_OPMODE_MODULAR
as we are building iwlwifi as a single module.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Pull in a case statement from the upcoming iwlwifi update to
unbreak the build after d875aa1587 .
Reported by: cy
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC with: d875aa1587
This is intended to be used with forthcoming ice(4) driver version 1.34.2.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Sponsored by: Intel Corporation
Fix the spelling of IEEE80211_HE_PHY_CAP9_NOMINAL_PKT_PADDING_*
(was "NOMIMAL"). The original version came from iwlwifi
in iwlwifi-next. Other drivers (from wireless-testing) already
use the correct spelling and need this change in LinuxKPI.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The firmware files for 3160, 7260, and 7265 imported contain old versions
no longer supported by the driver.
Replace with latest versions from linux-firmware to possibly also
support these chip revisions.
Reported by: FreeBSD User (freebsd walstatt-de.de) on wireless (2021-12-30)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
In certain situations we saw a memory modified after free. This was
tracked down to a pointer not NULLed after free and used in a different
code path. It is unclear how the race happens pending further
investigation but setting the pointer to NULL after free and adding a
check in the 2nd code path handling the case gracefully helps for now.
While here improve another debug messge in sta handling.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Cherry-pick f973795a8d19cbf3d03807704eb7c6ff65788d5a (Fix a double free
in iwl_txq_dyn_alloc_dma), db66abeea3aefed481391ecc564fb7b7fb31d742
(synchronize with FW after multicast commands),
d5d8ee526d1401173ad1261c3b6388a4f947e0a3 (remove session protection
upon station removal), and 8e967c137df3b236d2075f9538cb888129425d1a
(avoid clearing a just saved session protection id).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The 802.11 compat code is split off linuxkpi.ko into linuxkpi_wlan.ko
in case it is built as a module. Depend on that.
While here adjust our module to a longer version to avoid conflicts.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Over the past few months we published multiple snapshots for this
Linux derived driver and it has become fairly stable in terms of
minimal local changes needed for new updates.
The current version is based on iwlwifi-next update at
cbaa6aeedee5f92dafa5982eceea2a1f98ce4f7d with the addition of
a hand full of files replaced for FreeBSD.
Given the lack of full license texts on non-local files this is
imported under the draft policy for handling SPDX files (D29226). [1]
Do not yet hook this to the build until the remaining compat code
is all in. Along with the firmware import this will make publishing
the last bits and final testing a lot easier.
Sponsored by: The FreeBSD Foundation
Approved by: core (imp) [1]
MFC after: 10 days
Import the most recent versions of the firmware images for iwlwifi
chipsets supported by the "mvm" sub-driver.
This is based on linux-firmware at f5d519563ac9d2d1f382a817aae5ec5473811ac8.
The license of the firmware matches the previous iwnfw(4) and
iwmfw(4) firmware files and you can find a copy in
sys/contrib/dev/iwlwififw/LICENCE.iwlwifi_firmware .
Add build infrastructure to create the .ko files but do not yet hook
it up to the build until all parts are in the tree.
There is an open issue concerning kldxref that we need to resolve
(D32383).
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Clang 13.0.0 produces a new -Werror warning about the ACPI_TO_INTEGER(p)
and ACPI_OFFSET(d, f) macros in acpica's actypes.h:
sys/contrib/dev/acpica/components/dispatcher/dsopcode.c:708:31: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction]
ObjDesc->Region.Address = ACPI_PTR_TO_PHYSADDR (Table);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/contrib/dev/acpica/include/actypes.h:664:41: note: expanded from macro 'ACPI_PTR_TO_PHYSADDR'
#define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
^~~~~~~~~~~~~~~~~~
sys/contrib/dev/acpica/include/actypes.h:661:41: note: expanded from macro 'ACPI_TO_INTEGER'
#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sys/contrib/dev/acpica/include/actypes.h:656:82: note: expanded from macro 'ACPI_PTR_DIFF'
#define ACPI_PTR_DIFF(a, b) ((ACPI_SIZE) (ACPI_CAST_PTR (UINT8, (a)) - ACPI_CAST_PTR (UINT8, (b))))
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
This problem of undefined behavior was also reported to acpica by @cem
in 2018: https://github.com/acpica/acpica/issues/407, but it seems there
was never any fix committed for it upstream.
Instead fix these locally, for ACPI_TO_INTEGER by simply casting the
incoming pointer to ACPI_SIZE (which corresponds roughly to uintptr_t
and size_t), and for ACPI_OFFSET by reusing our __offsetof definition
from sys/cdefs.h.
Reviewed by: emaste, kib, imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D31710
The last commit (538ef055b7) accidentally
set the executable bits for this file. This is not intended to be
executed at all. (Would that even work?)
Sponsored by: Intel Corporation
This version is intended to be used with the 0.29.4 version of the
ice(4) driver, which will be be committed afterwards.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: stallamr_netapp.com
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D30887
The NAV (network allocation vector) register reflects the current MAC
tracking of NAV - when it will stay quiet before transmitting.
Other devices transmit their frame durations in their 802.11 PHY headers
and all devices that hear a frame - even if it's one in an encoding
they don't understand - will understand the low bitrate PHY header that
includes the frame duration. So, they'll set NAV to this value so
they'll stay quiet until the transmit completes.
Anyway, sometimes the PHY NAV header is garbled and sometimes, notably
older broadcom devices, will fake a long NAV so they can get "cleaner" air
for local calibration. When this happens, the hardware will stay quiet
for quite some time and this can lead to missed/stuck beacons, or
(for Very Large Values) a MAC hang.
This code just adds the ability to get/set the NAV; the driver will
need to take care of using it during transmit hangs and beacon misses
to see if it's due to a trash looking NAV.
This package is intended to be used with ice(4) version 0.28.1-k.
That update will happen in a forthcoming commit.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Sponsored by: Intel Corporation
