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
(cherry picked from commit 3d248a914d)
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
(cherry picked from commit e438f0a975)
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
(cherry picked from commit 538ef055b7)
(cherry picked from commit 070f7812da)
Update to the latest firmware based on
linux-firmware at c53073d4e1485ac9f7cb065db466793c495aead7
and update firmware module Makefiles accordingly.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 062103fc93)
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
(cherry picked from commit 51152e5e61)
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
(cherry picked from commit d9836fb4b9)
Add new defines, struct members, and (stub) functions needed for an
updated iwlwifi. Most of the defines are for rfkill or HE.
Pull in a case statement from the upcoming iwlwifi update to
not break the build.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit d875aa1587)
(cherry picked from commit 9ad210c159)
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
(cherry picked from commit e200809190)
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
(cherry picked from commit 58101517cb)
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
(cherry picked from commit 586c8e3233)
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
(cherry picked from commit 8f06a2b550)
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
(cherry picked from commit 81ff67ffbe)
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]
(cherry picked from commit bfcc09ddd4)
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
(cherry picked from commit f4c129f5fb)
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
Differential Revision: https://reviews.freebsd.org/D31710
(cherry picked from commit 130a690ae1)
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
(cherry picked from commit a7ac518bff)
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
Version 43 requires further modifications to iwm(4), and this was not
caught in some initial testing. Version 34 works and is the version
available on Intel's web site.
MFC with: r354201
Sponsored by: The FreeBSD Foundation
This is in preparation for adding the corresponding support to iwm(4).
Version 46 is the latest but contains unrecognized TLVs, so use version
43 for now.
Obtained from: linux-firmware
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Disable ar9300_swap_tx_desc() for the moment. It is an unused
function only tried to compile on big endian systems.
Found by: s390x buildkernel
MFC after: 3 months
Fix the reported boot failures and revert r350510.
Note this commit is effectively merging ACPICA 20190703 again and applying
an upstream patch.
https://github.com/acpica/acpica/commit/73f6372
Tested by: scottl
One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed. If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.
This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI. This allows it to know if it's a normal
operation or a scan operation.
This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.
Now, this isn't the full fix - ideally:
(a) all the ANI config and per-channel information would be migrated
to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
(like missed beacons, NF calibration failures, etc) a knob
to reset ANI parameters would likely help recovery.
But hey, I'm committing bits of code again! woo!
Tested:
* AR9344 (2G), STA operation
