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
My script to convert git commits to svn patch does not handle binary
files correctly, and r367387 committed a set of empty files as a result.
MFC with: r367387
Sponsored by: Rubicon Communications, LLC (Netgate)
This package is intended to be used with ice(4) version 0.26.16. That
update will happen in a forthcoming commit.
MFC after: 3 days
Sponsored by: Intel Corporation
The ice(4) driver is the driver for the Intel E8xx series Ethernet
controllers; currently with codenames Columbiaville and
Columbia Park.
These new controllers support 100G speeds, as well as introducing
more queues, better virtualization support, and more offload
capabilities. Future work will enable virtual functions (like
in ixl(4)) and the other functionality outlined above.
For full functionality, the kernel should be compiled with
"device ice_ddp" like in the amd64 NOTES file, and/or
ice_ddp_load="YES" should be added to /boot/loader.conf so that
the DDP package file included in this commit can be downloaded
to the adapter. Otherwise, the adapter will fall back to a single
queue mode with limited functionality.
A man page for this driver will be forthcoming.
MFC after: 1 month
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D21959
Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.
This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.
So:
* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.
This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.
The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.
Differential Revision: https://reviews.freebsd.org/D24981
Yes, people shouldn't use bitfields in C for structure parsing.
If someone ever wants a cleanup task then it'd be great to remove them
from this vendor code and other places in the ar9285/ar9287 HALs.
Alas, here we are.
AH_BYTE_ORDER wasn't defined and neither were the two values it could be.
So when compiling ath_ee_print_9300 it'd default to the big endian struct
layout and get a WHOLE lot of stuff wrong.
So:
* move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone.
* ensure that AH_BYTE_ORDER is actually defined before using it!
This should work on both big and little endian platforms.
Ok, yeah, the commit title is a bit misleading.
This has to do with CDD (cyclic delay diversity) - how this and later
wifi hardware transmits lower rates over more antennas. Eg, if you're
transmitting legacy 11abg rates on 2 or 3 antennas, you COULD just
send them all at the same time or you could delay each by tens/hundreds
of nanoseconds to try and get some better diversity characteristics.
However, this has a fun side effect - the antenna pattern is no longer
a bunch of interacting dipoles, but are a bunch of interacting dipoles
plus a bunch of changing phases. And it's frequency dependent - 50-200nS
is not exactly the same fraction of a wavelength across all of 2GHz or 5GHz!
Thus the power spectral density and maximum directional gain that you're
effectively getting is not .. well, as flat as it once was.
For more information, look up FCC/OET 13TR1003 in the FCC technical report
database. It has pretty graphics and everything.
Anyway, the problem lies thusly - the CDD code just subtracts another 3dB
or 5dB for the lower rates based on transmit antenna configuration.
However, it's not done based on operating configuration and it doesn't
take into account how far from any regulatory limits the hardware is at.
It also doesn't let us do things like transmit legacy rates and frames
on a single antenna without losing up to 5dB when we absolutely don't
need to in that case (there's no CDD used when one antenna is used!)
This shows up as the hardware behaving even worse for longer distance links
at 20MHz because, well, those are the exact rates losing a bunch more
transmit power.
* For lower power NICs (ie the majority of what is out there!) it's highly
unlikely we're going to hit anywhere near the PSD limits.
* It's doing it based on the existing limits from the CTL table (conformance
testing limits) - this isn't the regulatory max! It's what the NIC is
allowed to put out in each frequency and rate configuration! So things like
band edges, power amplifier behaviour and maximum current draw apply here.
Blindly subtracting 3 to 5dB from /this/ value is /very/ conservative..
* /and/ ath9k just plainly doesn't do any of this at all.
So, for now disable it and get the TX power back, thus matching what ath9k
in Linux is doing. If/once I get some more cycles I'll look at making it
a bit more adaptive and really only kick in if we're a few dB away from
hard regulatory limits.
Tested:
* AR9344 (2GHz + SoC, 2x2 configuration) - AP and STA modes
* QCA9580 (5GHz 2x2 and 3x3 configurations) - AP and STA modes
