Define the last missing PN length and for consistency use them
in struct ieee80211_key_seq (even though a 6 is a 6 is a 6).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
According to Documentation/core-api/dma-api.rst kmalloc() is supposd
to provide physically contiguous memory. [1]
In order to guarantee that allocations are contiguous even if using
PAGE_SIZE or larger check the size and use contigmalloc if needed.
This makes use of 9e6544dd6e (and following) allowing free(9) to
also work for contigmalloced memory.
Sponsored by: The FreeBSD Foundation
Pointed out by: jhb [1]
Reviewed by: jhb, emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46656
In linux_alloc_kmem() [used by *get_page*()] we always at least allocate
PAGE_SIZE and we want the allocation to be contiguous so it can be passed
to DMA. Always use kmem_alloc_contig() and only change the low argument
depending on the GFP_DMA32 flag being given or not.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: jhb, dumbbell
Differential Revision: https://reviews.freebsd.org/D46661
As indicated in 11db70b605 there was another panic on key removal
which could no longer be reproduced. As originally assumed the
problem was "hidden" by commit 9763fec11b as mentioned in
11db70b605.
Said commit had logic inverted and 27bf5c405b fixed that and with
that the possible panic came back.
The problem exists because some code paths out of net80211 are
locked while others are not. This opens a possible race in
net80211 which was tracked by extra logging in
(*iv_key_update_begin)() (log lines shortend):
key_update_begin: tid 100112 vap X nt Y unlocked
key_update_begin: tid 100133 vap X nt Y locked
One thread can be wpa_supplicant, the other is driven from the
driver net80211 taskq.
Further LinuxKPI needs to unlock (conditionally in case the lock
is held) as a downcall to the driver/FW may sleep. This opens up
possibilities for said race even further so that we observe it
more reliably.
This all leads to one thread calling down into the driver/firmware
(unlocked) while the other will get to the same place (after acquiring
the wiphy lock) before the nt re-lock happens and thus state checks
did not catch this either.
For LinuxKPI work around the problem utilizing
(*iv_key_update_begin/end)() and taking the wiphy_lock() there
holding it over the entire operation.
Given we still have to conditionally unlock we need to keep track
from _begin to _end on whether we have to re-lock. The checks for
this need to be done under the wiphy_lock().
While a bool would suffice we use a refcount to make any future
debugging easier.
This isn't the most elegant solution but having the wiphy lock
covering the full operation allows the 2nd thread to later run through
the same code path and find the key gone (which we already checked).
It remains questionable if (*iv_key_update_begin/end)() is the
correct solution (as there are futher callers covering which would
not need the unlock cycle) or if it should be done in the current
code. The former will allow us to cover a full key store which
we will need in case we will implement suspend/resume beyond what
is done in native drivers/net80211 currently, if we will factor
out the crypto locking for good, and fix the inconsistent locking
of the nt (NODE) lock in net80211.
Alternate solutions were discussed on freebsd-wireless today
(2025-03-06, in the thread "Re: HEADS UP! Do not update on main
currently (panic - on boot)").
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
X-MFC with: 27bf5c405b
Differential Revision: https://reviews.freebsd.org/D49256
net80211 used MMIC flags for CCMP instead of only for TKIP.
LinuxKPI 802.11 compat code (and later net80211) had a comment about
this. Given LinuxKPI seems to be the only consumer for these flags
currently outside of net80211 itself, clean them up before implementing
TKIP in LinuxKPI after all and before GCMP comes into the tree.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49219
net80211 ieee80211_node_get_txrate_dot11rate() does not yet support
VHT and that means we get a lot of log lines when doing VHT for a
debugging statement even if it's not active.
Remove the calls to ieee80211_node_get_txrate_dot11rate() as with
hw/fw based rate control (modern iwlwifi) they are pointless anyway
as they are currently.
Sponsored by: The FreeBSD Foundation
X-MFC: only if net80211 gets MFCed
Reported by: J.R. Oldroyd (jr opal.com)
Fixes: 7067450010 (I should have noticed during review)
There are only a few places where the returned rix is used:
* linuxkpi - logging
* bwi/bwn - used for finding a fallback rate to choose, which
honestly should be returned by the ratectl API
* iwm - building the rateset to program into firmware
Everyone else uses the dot11rate value in ni->ni_txnode.
This is a precursor for VHT and later rate support; where currently
there aren't rate tables in ieee80211_phy.c for VHT and later
rates.
Although it's likely doable to add tables for VHT, 11ax and MU-OFDMA
(HE) rates are sufficiently larger/different to just not fit in the
current scheme without more refactoring.
Differential Revision: https://reviews.freebsd.org/D48603
Reviewed by: bz, thj
This just mechanically converts things.
* For linuxkpi, it was just used for display.
* For uath, it was just used for display, as firmware
doesn't report it up.
Differential Revision: https://reviews.freebsd.org/D48602
Reviewed by: bz, thj
Compile in the VHT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20, HT40, VHT20, VHT40, VHT80)
If HT is enabled but not using CHW=40 set CHW=20 to make sure we do
not get stuck on any other value.
If VHT and the VHT Operation element Channel Width field is 0
(use 20/40) do not update the bandwidth but stick with what HT selected.
This is better than disabling VHT alltogether for 20/40 and allows us
to work on VHT20 and VHT40 APs it seems.
We will have to do more work to can align with the chanctx or deal with
Operating Mode Notification Action frames in LinuxKPI or net80211.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Compile in the HT compat code by default even though no one will make
use of it yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested with: iwlwifi AX210 (NOHT, HT20 and HT40)
For the moment we set dynamic_rx_chains to the rx_nss value which
should be correct given we count from 1 there too and we call
lkpi_get_max_rx_chains() after we synced ht/vht initially already.
Long-term some of these counting bits should be further factored
out into their own functions and used both here and for the sync
code.
This will likely want to change as well once more dyamic
synncronization takes place.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Clear IEEE80211_FHT_AMPDU_TX from iv_flags_ht to avoid doing A-MPDU TX.
For Intel we need to support two different variations at least, both
likely needing net80211 surgery first. The good news is that turning
it off in net80211 will make it work for modern iwlwifi/mvm chipsets/fw.
Realtek will need some mac80211 functions to be implemented at least.
Once we've done all and tested one after the other we can remove this
again.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Cleanup chanctx freq1/2 and width settings using the channel from the
net80211 node and the net80211 functions to return the center
frequencies (already doing the math for us or using pre-computed values).
Set the min_def (minimum channel definition) to def (channel definition)
for the moment as it seems to be unused by anything but
iwl_mvm_chanctx_def() to avoid complications.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Have a wrapper function dealing with the synchronization for all the
dfferent standards (HT and VHT currently).
In case HT or VHT is not supported make sure to turn the LinuxKPI
"supported" flag off for that. Previously if it was on once it would
never be turned off.
For HT and VHT properly compute the NSS and also set the max_amsdu_len
correctly.
Set the NSS directly in the function (which is called in proper order
for this) rather than passing the results back and do the setting in
the caller. The only thing we need to make sure upfront is that it
remains at least 1 (see f5a58c2da2). This all makes the caller and
code a tiny bit simpler and work better.
There is more synchronization to be done between the chanctx and the
deflink bandwidth, which needs to happen dynamically in case net80211
decides to change that under us but no native driver seems to properly
implement this (if at all).
HT20-only, HT40, and VHT80 are supposed to work for now at least.
VHT160 and VHT80P80 have further debug work to do as it does not yet
seem to be consistently set in all cases to sync from.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Make a pass over skbuff.h:
- implement some missing bits,
- sprinkle some const,
- add locking and read/write_once calls as needed to provide
synchronization as expected by Linux,
- fix some typos,
- remove return from void functions,
- adjust tracing macros.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 283903 (rtw88 skb leak)
Tested by: Guillaume Outters (guillaume-freebsd outters.eu)
Differential Revision: https://reviews.freebsd.org/D49101
net80211 has inconsistent locking when calling into (*ic_ampdu_rx_stop)().
Make use of 054c5ddf58 and conditionally check if the caller
locked or not and if locked temporary drop the lock to avoid sleeping
on a non-sleepaable lock during the downcall into the driver.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
ieee80211_sta_recalc_aggregates() shows up in TODO traces but there is
nothing we have to do there until we have active links (MLO support).
Make the TODO conditional for a time when we will get there.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Define cfg80211 IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK to
net80211 IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK.
We should likely at some point make a sweep and replace all the
values with the defines from the comments for the matching net80211
version.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
When setting the per-band supp_rates bitfield check for mandatory
rates only. We cannot easily say at that point for 2Ghz whether
11g is supported so assume these days it is not pure-b.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Implement cfg80211_chandef_create() to work with HT. Update enum
with HT channel types. When calling the function from LinuxKPI 802.11
code, pass in NL80211_CHAN_HT20 if HT is supported rather than NO_HT.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
They are used by the DRM drivers in Linux 6.7.
Bump `FreeBSD_version` because external drivers that use `struct
shrinker` will have to be recompiled.
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48747
This helps developers working with linuxkpi find out a function is
already defined but is just a stub.
Reported by: bz
Reviewed by: bz, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48862
Commit 03e39d3d42 decreased the Linux
version that exposes this constant to be Linux 6.7. It happens that the
constant is older.
However, it is removed in Linux 6.10. Let's change the version condition
to say that it is defined for any version before 6.10.
Reported by: bz
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48861
To use the old version, one has to explicitly set `LINUXKPI_VERSION` to
the expected version of Linux KPI.
Reported by: bz
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48860
We ran into problems with locking the VIF for the lsta tailq on and
off. Switch from a native tailq to the LinuxKPI list.
This allows us to implement the "rcu" part in
linuxkpi_ieee80211_iterate_keys() which we could not before.
Further using either rcu or the wiphy lock we no longer run into
problems with the lock not being sleepable.
The last case was rtw89 debugfs which was doing a sleepable alloc
in the iterator callback of linuxkpi_ieee80211_iterate_stations_atomic().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Rather than just printing the cipher suite as uint32_t hex
(or split into OUI and number) also print a short name.
iwlwifi(4), for example, now prints on startup with HW_CRYPTO on:
unsupported WLAN Cipher Suite 0x000fac | 8 (GCMP)
unsupported WLAN Cipher Suite 0x000fac | 9 (GCMP_256)
unsupported WLAN Cipher Suite 0x000fac | 6 (AES_CMAC)
unsupported WLAN Cipher Suite 0x000fac | 11 (BIP_GMAC_128)
unsupported WLAN Cipher Suite 0x000fac | 12 (BIP_GMAC_256)
Likewise _lkpi_iv_key_set() would now print:
iwlwifi0: _lkpi_iv_key_set: CIPHER SUITE 0xfac02 (TKIP) not supported
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Implement mac80211 functions ieee80211_iter_keys[_rcu](), and
ieee80211_get_key_rx_seq() (*).
Implement an internal function lkpi_sta_del_keys() to delete keys
when we are leaving RUN (AUTHORIZED) state.
Improve and make work (*) the net80211 vap function pointers
(*iv_key_set)(), (*iv_key_delete)() implementations.
Correct the logic in lkpi_80211_txq_tx_one() and factor most crypto
related bits out into lkpi_hw_crypto_prepare() (*).
(*) We are currently supporting CCMP only. I would hope we will
not have to do full WEP/TKIP support anymore given both are deprecated.
The entire logic remains behind the LKPI_80211_HW_CRYPTO pre-processor
condition and with this commit in addition behind a tunable.
The code is compiled in by default now but the tunable remains off until
wider testing has shown no problems.
I have seen one net80211 triggered panic on shutdown related to deleting
keys which I cannot reproduce anymore and could have been fixed by
9763fec11b83; otherwise we will have to investigate as it shows again.
The dedicated hw crypto tracing option can help in that case with debug
kernels.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Fixes: b35f6cd066
Implement the mac80211 (*sta_statistics) to obtain station statistics.
Fix up struct station_info for that.
Add supporting funtions to decode station_info and rate_info_bw fields
to make the output more usable to human beings.
Add a per-VIF (VAP) sysctl to export that information. This is mostly
used for now to see what the driver/fw thinks about its TX rate.
We should later gather this information in different ways and pass it
to net80211 to export it to user space so we can finally have nice
station information (also for the non-AP side).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
rtw88 seems to have an skb leak still.
Add a WARN_ONCE to __skb_queue_purge() just to make sure there is no
glitch due to missing locking.
Also add a rolling error reporting for skb allocation failures in
LinuxKPI to gather some more information if possible about queue
states.
This is a corrected version of what was initially part of D48474.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
ieee80211_vif_usable_links() shows up in TODO() tracking.
Turns out the return (1) is likely wrong and should be 0 given we do
not support MLD yet. For now return the valid_links bitmap and leave
an IMPROVE as likely not all of the valid ones will be useable.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
For now we only return the legacy rate and have two TODOs for HT and
VHT which still need to be implemented as needed.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Given I was looking at the struct make it more packed at the beginning
at least. In fact it did not shrink but the tx_time_est got expanded.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Convert a lot more LinuxKPI rx_status fields to net80211 rx_stats
bits for as much as we can see fit. Factor the entire logic out
into its own function as it got quite long.
Now only net80211 needs to start using more of these values and
report them.
Also fix some related fields and struct definitions in LinuxKPI.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
There are cases when we see "rx seq# violation (CCMP)".
Historically these were AHDEMO/IBBS cases (IEEE80211_KEY_NOREPLAY,
see 5d766a09da).
With iwlwifi(4) doing RSS for newer chipsets and us not having any idea
about multiple rx-queues (passed all the way through) leads to the same
problem. An easy way to trigger this is doing an IPv6 all-nodes echo
request. With a sufficient amount of nodes answering the answers will
be hashed to different queues and re-ordering will likely take place
as queues get released individually.
However crypto validation is already done in fw/driver for these cases
and we need to carry the state forward. Add IEEE80211_RX_F_PN_VALIDATED
to indicate that the checks were done passing the information from driver
through LinuxKPI to net80211.
LinuxKPI enforces that a frame was indeed decrypted; otherwise the flag
would be invalid.
This also avoids returning an error and no key from
ieee80211_crypto_decap() and thus avoids dropping the frame.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D49029
Implement ieee80211_rate_set_vht(), ieee80211_rate_get_vht_{mcs,nss}(),
and ieee80211_get_vht_max_nss().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Until net80211 will grow proper scan offload with the various options
needed and will allow switching the scan engine try to improve the
situation if we are doing a hw_scan and the device supports
SINGLE_SCAN_ON_ALL_BANDS. In that case create the channel list from
our device information of supported channels rather than from the
net80211 scan list. Filter out currently unsupported bands.
While the general "scan EBUSY" problem remains at least in my local
testing I am seeing a lot more 2 and 5 GHz band results rather than
being stuck on a single band (as was also often the case with iwm for
me in the past).
Tested by: rene (previous version)
MFC after: 3 days
Add the mask and shift for the VHT Extended NSS BW Support field.
Document them in net80211 and further related bitmasks in LinuxKPI.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D48975
Add this attribute which is a no-op for us but in linux represent that
the guest memory encryption is active.
drm ttm started to check this flag in > 6.1.92
Sponsored by: Beckhoff Automation GmbH & Co. KG
Linux has removed timespec_to_jiffies() half a decade ago [1].
I cannot find any use of it anymore in recent drm-kmod branches
or in the tree so retire it.
While here also retire it from drm2.
Reported by: emaste (D48318) [1].
Sponsored by: The freeBSD Foundation
MFC after: 2 weeks
Reviewed by: emaste, dumbbell (tested all drm-kmod versions, thanks!)
Differential Revision: https://reviews.freebsd.org/D48379
Implement the combination of all four functions, the *_vif versions
from mac80211.h as a wrapper to the non-*_vif ones in cfg80211.h.
Put the function pairs next to each other and in the right files
and harmonize argument naming, etc.
Both of them have shown up too often in the todo-tracing to bother
enough to implement them now for a time in the future when we will
support HE/EHT.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Given the channel struct has an extra bool we cannot assign the
information 1:1 to net80211. While the caps where assigned the
suppoerted mcs sets were not. Fix that.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
[Why]
The mutex initialized in `xa_init_flags()` is not destroyed here on
purpose. The reason is that on Linux, the xarray remains usable after a
call to `xa_destroy()`. For instance the i915 DRM driver relies on that
during the initialixation of its GuC. Basically, `xa_destroy()` "resets"
the structure to zero but doesn't really destroy it.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48762
[Why]
This function is used by hhe DRM generic code starting with Linux 6.7.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48761
[Why]
The i915 DRM driver relies on this chain of includes to access the
definition of `struct tasklet_struct` in `<linux/interrupt.h>`.
Reviewed by: imp, manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48760
