LinuxKPI: 802.11: fix rx_nss with VHT
When fixing single-stream chipsets, like iwlwifi(4) AX101, we started
masking the announced with the hardware supported values. This would
probably limit, e.g., rx_nss. During these works we fixed a loop
checking from the highest nss=7 to lowest nss=0 (8..1) and would set
rx_nss if the stream was supported. This left us with always setting
rx_nss on nss=0 to nss + 1 = 1. Instead only update once when we hit
the first supported MCS value (highest number of supported streams).
Looking at the diff of the mentioned commit hash which gets fixed it
looks like even the old code was not correct either.
This only fixes the logic to calculate rx_nss. This does not yet help
with modern drivers to actually update the value. Code for this will
come in a later commit.
Sponsored by: The FreeBSD Foundation
Fixes: adb4901ac9ae
(cherry picked from commit 8494be1b5af7fe4f765532f802ac0a145e061d73)
LinuxKPI: 802.11: assign sequence numbers to frames
While all native drivers were converted to call
ieee80211_output_seqno_assign() after changes to net80211 if needed,
LinuxKPI 802.11 was not fixed. Add the missing call.
Given we are currently only supporting STA mode, we can provide
sequence numbers for all frames (mgmt/beacon would be a problem in
AP mode).
This greatly helps LinuxKPI based drivers other than iwlwifi(4).
If drivers do their own sequence numbers, they will overwrite what we
pre-set unless we would pass a txflag not to do so (beware the
consequences).
Sponsored by: The FreeBSD Foundation
Fixes: eabcd1773fa3, 785edcc2af5a
(cherry picked from commit 9cf85457b13bc7aa125388d63c82acf2b21e9e9e)
LinuxKPI: 802.11: reset hdr after crypto in lkpi_80211_txq_tx_one()
When lkpi_80211_txq_tx_one() calls into the crypto offloading parts to
possibly make space in the headroom, the beginning of our frame moves.
We have to reset hdr after that call as otherwise later classifications
based on the hdr->frame_control will fail or cause wrong classificaiton
of packets.
This makes sure frames will either be directly sent using (*mo_tx)()
or use the correct tid for the correct queue. This helps to get
rtwx8 packets flowing after BA was negotiated.
Sponsored by: The FreeBSD Foundation
Fixes: 11db70b6057e4
(cherry picked from commit f0395993e1ea83705e0da6623843e7d5d03f7269)
LinuxKPI: 802.11: add compat.linuxkpi.80211.IF.dump_stas_queues
Extend the normal compat.linuxkpi.80211.IF.dump_stas sysctl by
queue information. This was helpful for debugging various issues,
like selecting the outbound queue, stopping queues for BAR and helped
finding multiple bugs.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 32ea8209825af594cbfa1fc654d45eb9a6aab528)
sys/bitcount.h: add __const_bitcount<n>
Add a version of __const_bitcount<n> which can be used to get the
numbers at compile-time when __builtin_popcountg() is not available
(see sys/compat/linuxkpi/common/include/linux/bitops.h for LLVM before
19 and gcc before 14).
Obtained from: https://reviews.freebsd.org/D50995#1174884 by obiwac
Sponsored by: The FreeBSD Foundation
Reviewed by: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D54301
(cherry picked from commit 27aa23cee81088b0ffa974eec9f03c654c36438e)
LinuxKPI: bitcount fix builds with gcc and older llvm
LLVM before 19 and gcc before 14 do not support __builtin_popcountg().
Use __const_bitcount<n> from sys/bitcount.h as a replacement in these
cases. This should still allow drm-kmod to build where the size needs
to be known at compile-time.
Remove the conditional for gcc around the iwlwifi modules build,
which was collateral damage in all this.
Sponsored by: The FreeBSD Foundation
Fixes: 7cbc4d875971, 5e0a4859f28a
Reviewed by: brooks, emaste (without the sys/modules/Makefile change)
Differential Revision: https://reviews.freebsd.org/D54297
(cherry picked from commit 34892a8e30055000352d9612ad985be550c82bea)
[X86] SimplifyDemandedVectorEltsForTargetNode - add basic X86ISD::PCLMULQDQ handling (#176142)
Now that we're creating X86ISD::PCLMULQDQ nodes in DAG, we need to
handle basic vector simplification - a minor first step towards adding
ISD::CLMUL vector handling
X86ISD::PCLMULQDQ uses the lower/upper i64 element from each 128-bit
lane depending on whether bit0/bit4 are set (for lhs/rhs operands)
These tests were copied from InstCombine which already did something
similar for the pclmulqdq intrinsics
[InstSimplify] Avoid poison value for ctz/abs in simplifyWithOpsReplaced() (#176168)
If we drop flags, we'll set the zero_is_poison/int_min_is_poison flag to
false as part of the transform. However, the constant folding was still
performed with the value true, which made constant folding return
poison. This resulted in the pattern failing to match, as the poison
value is not equal to the other select arm.
To avoid this, add some special handling to set the argument to false
during constant folding as well.
Fixes https://github.com/llvm/llvm-project/issues/175282.
[cmake] Restore exception flags in llvm-config --cxxflags (#176195)
https://github.com/llvm/llvm-project/pull/173869 accidentally dropped
rtti and eh flags from `llvm-config --cxxflags`. Then
https://github.com/llvm/llvm-project/pull/174084 restored the rtti
flags. The eh flags were not included with the rationale that they are
not ABI relevant.
This PR restores the eh flags as well. While they are not strictly
necessary, I believe that code that directly interfaces with LLVM almost
certainly does not want to build with exceptions if LLVM is not built
with exceptions. Building in the peculiar `-fexceptions -fno-rtti`
configuration is rarely useful and likely not intended.
On MacOS, this is also relevant because it's not possible to use C++17
headers without `-fno-exceptions` when using older deployment targets.
In that configuration, `-fno-exceptions` is required to interact with
LLVM.
