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
[Why]
This is used by the amdgpu DRM driver starting with Linux 6.7.
[How]
The function just returns 0 for now.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48759
[Why]
This is used by the amdgpy DRM driver starting from Linux 6.7.
[How]
The function always returns false, like `pci_is_thunderbolt_attached()`
because we don't have an API for this in FreeBSD yet.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48758
[Why]
This is used by the i915 DRM driver starting from Linux 6.7.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48757
[Why]
In Linux 6.7, the signature of `get_file_rcu()` changed significantly,
going from:
bool get_file_rcu(struct linux_file *f);
... to:
struct linux_file * get_file_rcu(struct linux_file **f);
I.e., both the argument and the return value changed in an incompatible
way.
This is used by the i915 DRM driver.
[How]
This patch introduces the variant and hide the new prototype behind
`LINUXKPI_VERSION >= 60700`.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48756
[Why]
The i915 DRM driver started to access the `xa_lock` field in Linux 6.7.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48754
[Why]
This function is used by the i915 DRM driver starting with Linux 6.7.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48753
[Why]
This function is used by the i915 DRM driver in Linux 6.7.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48752
[Why]
Some files in the i915 DRM driver in Linux 6.7 depend on these implicit
inclusions.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48751
