Kees Cook [Wed, 7 Feb 2024 10:30:33 +0000 (02:30 -0800)]
wifi: mwifiex: Refactor 1-element array into flexible array in struct mwifiex_ie_types_chan_list_param_set
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip
the array bounds sanitizer[1]. Only a few places were using sizeof()
on the whole struct, so adjust those to follow the calculation pattern
to avoid including the trailing single element.
Examining binary output differences doesn't appear to show any literal
size values changing, though it is obfuscated a bit by the compiler
adjusting register usage and stack spill slots, etc.
Link: https://github.com/KSPP/linux/issues/51 Cc: Brian Norris <briannorris@chromium.org> Cc: Kalle Valo <kvalo@kernel.org> Cc: Dmitry Antipov <dmantipov@yandex.ru> Cc: Johannes Berg <johannes.berg@intel.com> Cc: zuoqilin <zuoqilin@yulong.com> Cc: Ruan Jinjie <ruanjinjie@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240207103024.make.423-kees@kernel.org
ATWILC1000/ATWILC3000
Baremetal Wi-Fi/BLE Link Controller Software Design Guide
https://tinyurl.com/yer2xhyc
says that bit 0 of the CRC7 code must always be a 1.
I confirmed that today with a logic analyzer: setting bit 0 causes
wilc1000 to accept a command with CRC7 enabled, whereas clearing bit 0
causes wilc1000 to reject the command with a CRC error.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:24 +0000 (11:06 +0800)]
wifi: rtw89: chan: MCC take reconfig into account
During mac80211 reconfig, chanctx ops of multiple channels might not
be called in order as normal cases. However, we expect the first active
chanctx always to be put at our sub entity index 0. So, if it does not,
we do a swap there. Besides, reconfig won't allocate a new chanctx object.
So, we should reset the reference count when ops add chanctx.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:23 +0000 (11:06 +0800)]
wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLO
After MLO, we will need to consider not only active chanctx but also active
interfaces (roles) to decide entity things. So in advance, we move handling
from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then,
we can recalculate and aware active interfaces' changes.
For now, behavior should not be really different, since active chanctx and
active interface are one-to-one mapping before MLO.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:22 +0000 (11:06 +0800)]
wifi: rtw89: chan: tweak weight recalc ahead before MLO
Originally, we consider weight only based on how many chanctxs that
mac80211 sets. However, we need to consider both active chanctxs and
active interfaces to distinguish MCC (multiple channel concurrent)
from impending MLO.
Although the logic of handling is extended, for now, behavior might
not be different under current condition.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:21 +0000 (11:06 +0800)]
wifi: rtw89: chan: tweak bitmap recalc ahead before MLO
Originally, we just declared two sub-entity, and according to rolling
down mechanism, we ensured that index 0 contained sub-entity as long
as there are sub-entity. So, we could use for-loop after deciding the
last index.
But, we are preparing to expand num of sub-entity for MLO. Then, there
won't be just two sub-entity. And, there might be holes between two bits
in the bitmap. So, we cannot simply do for-loop as before. Instead, we
need to follow the set bits.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:20 +0000 (11:06 +0800)]
wifi: rtw89: chan: add sub-entity swap function to cover replacing
Originally, we replaced sub-entity of index 0 with another one in some
cases. However, we will need a swap here in following implementations.
So, we introduce it ahead and change code from replacing to swapping.
Zong-Zhe Yang [Tue, 6 Feb 2024 03:06:19 +0000 (11:06 +0800)]
wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by self
Some of our calculation during concurrent mode depend on last beacon
TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get
what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will
be restricted once we declare MLO.
Since we are about to consider the MLO stuffs, so sync beacon TSF by
ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY.
Ajay Singh [Mon, 15 Jan 2024 14:56:30 +0000 (15:56 +0100)]
wifi: wilc1000: set preamble size to auto as default in wilc_init_fw_config()
WILC driver currently applies some default configuration whenever the firmware
is initialized, and sets the default preamble size to short. However, despite
this passed option, firmware is also able to successfully connect to access
points only using long preamble, so this setting does not really enforce short
preambles and is misleading regarding applied configuration.
Update default configuration and make it match the firmware behavior by passing
the existing WILC_FW_PREAMBLE_AUTO value (2 instead of 0). The updated setting
does not really alter firmware behavior since it is still capable to connect to
both short preamble and long preamble access points, but at list the setting now
expresses for real the corresponding firmware behavior.
More info: it has been implemented to address the transmission (Tx) blackout
issue observed in the 802.11b mode. The modification has no impact on the other
modes, which will continue to work as they did in the previous implementation.
This change will allow the 802.11b transmission (2, 5.5, 11Mbps) to use long
preamble.
Dmitry Antipov [Wed, 10 Jan 2024 11:53:11 +0000 (14:53 +0300)]
wifi: mwifiex: use kstrtoX_from_user() in debugfs handlers
Use convenient 'kstrtou32_from_user()' in 'mwifiex_verext_write()'
and 'kstrtobool_from_user()' in 'mwifiex_timeshare_coex_write()',
respectively. Compile tested only.
Arnd Bergmann [Mon, 12 Feb 2024 11:23:36 +0000 (12:23 +0100)]
wifi: iwlwifi: fix #ifdef CONFIG_ACPI check
The #ifdef check around the function definition for two functions was
changed without also changing the one on the declaration:
drivers/net/wireless/intel/iwlwifi/fw/uefi.c:359:6: error: redefinition of 'iwl_uefi_get_sgom_table'
359 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans,
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/net/wireless/intel/iwlwifi/fw/uefi.c:11:
drivers/net/wireless/intel/iwlwifi/fw/uefi.h:294:6: note: previous definition of 'iwl_uefi_get_sgom_table' with type 'void(struct iwl_trans *, struct iwl_fw_runtime *)'
294 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans, struct iwl_fw_runtime *fwrt)
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/fw/uefi.c:392:5: error: redefinition of 'iwl_uefi_get_uats_table'
392 | int iwl_uefi_get_uats_table(struct iwl_trans *trans,
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/fw/uefi.h:299:5: note: previous definition of 'iwl_uefi_get_uats_table' with type 'int(struct iwl_trans *, struct iwl_fw_runtime *)'
299 | int iwl_uefi_get_uats_table(struct iwl_trans *trans,
| ^~~~~~~~~~~~~~~~~~~~~~~
Adapt it by merging the declarations into the existing #ifdef block.
Fixes: 74f4cd710705 ("wifi: iwlwifi: take SGOM and UATS code out of ACPI ifdef") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://msgid.link/20240212112343.1148931-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Feb 2024 16:02:14 +0000 (18:02 +0200)]
wifi: iwlwifi: queue: improve warning for no skb in reclaim
We've seen this warning trigger, and while the reason is
probably obvious, I haven't been able to see it yet. Add
more information to the warning message to help identify
the cause. Also print out both index and SSN for all the
messages.
Johannes Berg [Tue, 6 Feb 2024 16:02:13 +0000 (18:02 +0200)]
wifi: iwlwifi: mvm: move BA notif messages before action
This is always a bit confusing, the code first does all the
reclaim (with its own debug messages), and _then_ prints it
got a BA notification from firmware. Turn that around.
Johannes Berg [Tue, 6 Feb 2024 16:02:09 +0000 (18:02 +0200)]
wifi: iwlwifi: mvm: don't set replay counters to 0xff
The firmware (later) actually uses the values even for keys
that are invalid as far as the host is concerned, later in
rekeying, and then only sets the low 48 bits since the PNs
are only 48 bits over the air. It does, however, compare the
full 64 bits later, obviously causing problems.
Remove the memset and use kzalloc instead to avoid any old
heap data leaking to the firmware. We already init all the
other fields in the struct anyway. This leaves the data set
to zero for any unused fields, so the firmware can look at
them safely even if they're not used right now.
wifi: iwlwifi: mvm: don't set the MFP flag for the GTK
The firmware doesn't need the MFP flag for the GTK, it can even make the
firmware crash. in case the AP is configured with: group cipher TKIP and
MFPC. We would send the GTK with cipher = TKIP and MFP which is of course
not possible.
Johannes Berg [Tue, 6 Feb 2024 16:02:05 +0000 (18:02 +0200)]
wifi: iwlwifi: fw: allow vmalloc for PNVM image
This image can be pretty big (I've seen order-7 allocations!),
and we later have to copy it to DMA memory (in newer FW even
there it won't need to be contiguous), so we can easily deal
with it being in vmalloc. Use kvmemdup()/kvfree() for it.
Johannes Berg [Mon, 5 Feb 2024 19:21:15 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: don't do duplicate detection for nullfunc packets
For non-QoS nullfunc packets we currently do the duplicate detection,
which seems a bit wrong. Fix the code to check for _any_ instead of
just _qos_ nullfunc.
Also remove setting the RX_FLAG_DUP_VALIDATED flag, we haven't done
anything here; in particular, we haven't checked for multicast in an
MLO scenario.
Johannes Berg [Mon, 5 Feb 2024 19:21:14 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: fix erroneous queue index mask
When retrieving the queue index ("SCD SSN") from the TX response,
it's currently masked with 0xFFF. However, now that we have queues
longer than 4k, that became wrong, so make the mask depend on the
hardware family.
This fixes an issue where if we get a single frame reclaim while
in the top half of an 8k long queue, we'd reclaim-wrap the queue
twice (once on this and then again on the next non-single reclaim)
which at least triggers the WARN_ON_ONCE() in iwl_txq_reclaim(),
but could have other negative side effects (such as unmapping a
frame that wasn't transmitted yet, and then taking an IOMMU fault)
as well.
Shaul Triebitz [Mon, 5 Feb 2024 19:21:13 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: avoid garbage iPN
After waking from D3, we set the iPN given by the firmware.
For some reason, CIPHER_SUITE_AES_CMAC was missed.
That caused copying garbage to the iPN - causing false replays.
(since 'seq' is on the stack, and the iPN from the firmware
was not copied into it, it contains garbage which later is
copied to the iPN key).
Johannes Berg [Mon, 5 Feb 2024 19:21:11 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: limit pseudo-D3 to 60 seconds
With unlimited pseudo-D3, we can get stuck here in the read if
the firmware never wakes up. All of our testing infrastructure
however will anyway give up after at most a minute, so there's
no value in that.
Limit this to about a minute to avoid getting stuck with the
RTNL held forever, which basically makes the machine unusable
and then we can't even understand what caused the failure.
Shaul Triebitz [Mon, 5 Feb 2024 19:21:09 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: fix the key PN index
When waking from D3 (and a GTK rekey happened during
D3), the key itself is saved in iwl_wowlan_status_data::gtk
array, but the PN is saved in iwl_wowlan_status_data::gtk_seq
array.
The indices (of the same key) might differ in both arrays.
Fix using the gtk array index in the gtk_seq array.
Rather, iterate and search for the correct key in the
gtk_seq array.
Daniel Amosi [Mon, 5 Feb 2024 19:21:07 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: Keep connection in case of missed beacons during RX
The client needs to disconnect from AP in case of more than 19 missed
beacons only if no data is coming from that AP, otherwise it needs to
stay connected.
Miri Korenblit [Mon, 5 Feb 2024 19:21:05 +0000 (21:21 +0200)]
wifi: iwlwifi: properly check if link is active
Before sending SESSION PROTECTION cmd the driver verifies that the
link for which the cmd is going to be sent is active.
The existing code is checking it only for MLD vifs,
but also the deflink (in non-MLD vifs) needs to be active in order
the have a session protection for it.
Fix this by checking if the link is active also for non-MLD vifs
Miri Korenblit [Mon, 5 Feb 2024 19:21:04 +0000 (21:21 +0200)]
wifi: iwlwifi: take SGOM and UATS code out of ACPI ifdef
The BIOS tables SGOM and UATS are read from UEFI, but require
additional tables (WGDS and DSM func 3, respectively) which used to be
read from ACPI only, so the code handling those tables had to be under
ifdef ACPI. But now the driver reads those tables (WGDS and DSM) from
both ACPI and UEFI, so SGOM and UATS code shouldn't be under ifdef ACPI
anymore.
Johannes Berg [Mon, 5 Feb 2024 19:21:03 +0000 (21:21 +0200)]
wifi: iwlwifi: mvm: don't abort queue sync in CT-kill
CT kill should stop doing a lot of TX etc. to cool down the
NIC, but we don't stop all commands from going to the NIC,
and as such we shouldn't abort queue sync, since it can get
confused if we do, warning that we do it twice at the same
time etc. Only stop it when we'd also not send it in the
first place.
Johannes Berg [Sun, 4 Feb 2024 22:06:17 +0000 (00:06 +0200)]
wifi: iwlwifi: mvm: remove one queue sync on BA session stop
As documented in the comment, this queue sync was here to
ensure that an async IWL_MVM_RXQ_NSSN_SYNC queue sync won't
race with setting up a new BA session with the same BAID.
However, we no longer do IWL_MVM_RXQ_NSSN_SYNC queue sync,
so we can remove this as well.
Miri Korenblit [Sun, 4 Feb 2024 22:06:08 +0000 (00:06 +0200)]
wifi: iwlwifi: adjust rx_phyinfo debugfs to MLO
This debugfs entry is used to configure the rx_phyinfo.
Currently we are sending the phy cmd only for the deflink.
Change it to send the cmd for all active links of the vif
Anjaneyulu [Sun, 4 Feb 2024 22:06:06 +0000 (00:06 +0200)]
wifi: iwlwifi: Add support for PPAG cmd v5 and PPAG revision 3
Add support for
- PPAG revision 3 in BIOS to enable PPAG in UHB
- PPAG command version 5, this command allows OEM to control
enablement of PPAG for LPI for UHB mode in USA and ETSI countries.
Johannes Berg [Sun, 4 Feb 2024 22:06:05 +0000 (00:06 +0200)]
wifi: iwlwifi: pcie: don't allow hw-rfkill to stop device on gen2
On new devices the HW rfkill shutdown doesn't need to be handled
"as fast as possible", so disallow the immediate shutdown mode
here via documentation and a warning.
wifi: mac80211: add support to call csa_finish on a link
Currently ieee80211_csa_finish() function finalizes CSA by scheduling a
finalizing worker using the deflink. With MLO, there is a need to do it
on a given link basis.
Pass link ID of the link on which CSA needs to be finalized.
wifi: mac80211: handle set csa/after_csa beacon on per link basis
In order to support CSA with MLO, there is a need to handle the functions
ieee80211_set_csa_beacon() and ieee80211_set_after_csa_beacon() on a per
link basis.
Implement this by making the function argument accept the the link data
instead of the sdata.
Currently, deflink would only be passed. Proper link data will be passed in
a subsequent patch.
wifi: mac80211: update beacon counters per link basis
Currently, function to update beacon counter uses deflink to fetch
the beacon and then update the counter. However, with MLO, there is
a need to update the counter for the beacon in a particular link.
Add support to use link_id in order to fetch the beacon from a particular
link data during beacon update counter.
wifi: cfg80211: send link id in channel_switch ops
Currently, during channel switch, no link id information is passed down.
In order to support channel switch during Multi Link Operation, it is
required to pass link id as well.
Add changes to pass link id in the channel_switch cfg80211_ops.
Michael-CY Lee [Fri, 22 Dec 2023 01:09:14 +0000 (09:09 +0800)]
wifi: mac80211: refactor STA CSA parsing flows
The new Wi-Fi Standard (IEEE Std 802.11-2020 9.4.2.160) specifies that
the Wide Bandwidth Channel Switch (WBCS) Element subfields have the same
definitions as VHT operation information if the operating band is not
S1G.
The problem comes when the BSS is in 6 GHz band, the STA parses the WBCS
Element by ieee80211_chandef_vht_oper(), which checks the capabilities for
HT/VHT mode, not HE/EHT mode.
This patch refactors STA CSA parsing flow so that the corresponding
capabilities can be checked. Also, it adds the way to use op_class in ECSA
Element to build a new chandef.
In summary, the new steps for STA to handle CSA event are:
1. build the new chandef from one of the CSA-related (Sub)Elements in
following order,
- Bandwidth Indication (Sub)Element
- Wide Bandwidth Channel Switch (Sub)Element
- Operating class in Extended Channel Switch Announcement Element
- Channel Switch Announcement Element
2. convert the new chandef into operation information according to the
operating band in order to check if the new chandef fits STA's
capabilities.
3. downgrade the bandwidth until current bandwidth is not disabled.
Co-developed-by: Money Wang <money.wang@mediatek.com> Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://msgid.link/20231222010914.6521-3-michael-cy.lee@mediatek.com
[rebase on top of the changes with struct ieee80211_conn_settings,
prefer leXY_encode_bits()] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 7 Feb 2024 10:59:20 +0000 (11:59 +0100)]
wifi: mac80211: don't use sband->band early
Some drivers may (notably mt76 does) not set up sband->band
before registering, and cfg80211 will fill it in later. But
since the HT/HE capability check mac80211 required it to be
initialized already, otherwise failing things. This really
isn't necessary though since the code is iterating the list
of bands, and has the 'band' variable available. Fix it to
not require the sband->band to be initialized already.
Fixes: f04d2c247e04 ("wifi: mac80211: disallow drivers with HT wider than HE") Reported-by: Bert Karwatzki <spasswolf@web.de> Debugged-by: Bert Karwatzki <spasswolf@web.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218466 Link: https://msgid.link/20240207115920.43cbedffb5c3.I4968e12275a3f95926e3f3ccae81e50f23fe4d4d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 31 Jan 2024 15:49:11 +0000 (16:49 +0100)]
wifi: mac80211: clarify vif handling in TX dequeue
The vif pointer at least looks like it can actually be NULL
in some cases such as the monitor-mode vif, causing static
checkers to complain with the immediate derefence. In these
cases the sta pointer will also be NULL, but clarify it in
the code anyway.
Johannes Berg [Mon, 29 Jan 2024 19:35:45 +0000 (20:35 +0100)]
wifi: mac80211: allow CSA to same channel
This could be used e.g. for temporarily sending quiet
(mode=1 in CSA/ECSA), or updating bandwidth. This is
also useful for testing, since it's something that an
AP may do and the client needs to be prepared. Simply
allow it.
Johannes Berg [Mon, 29 Jan 2024 19:19:33 +0000 (20:19 +0100)]
wifi: mac80211: start building elements in SKBs
The building of elements is really mess, and really the only
reason we're not doing it in SKBs in the first place is that
the scan code in ieee80211_build_preq_ies() doesn't.
Convert ieee80211_build_preq_ies() to use an SKB internally
so that we can gradually convert other things to ..._put_*()
style interfaces.
Johannes Berg [Mon, 29 Jan 2024 19:19:31 +0000 (20:19 +0100)]
wifi: mac80211: tdls: use ieee80211_put_he_6ghz_cap()
We don't need to use the write function here since we already
have an SKB, so use ieee80211_put_he_6ghz_cap() with the SMPS
mode taken from the link we're using.
The term 'IE' isn't really in use in the spec, and I want
to rework all of this to use SKBs as the primary method
for building elements. Rename this one already.
Johannes Berg [Mon, 29 Jan 2024 19:19:28 +0000 (20:19 +0100)]
wifi: mac80211: adjust EHT capa when lowering bandwidth
If intending to associate with a lower bandwidth, remove capabilities
related to 320 MHz from the EHT capabilities element. Also change the
EHT MCS-NSS set accordingly: if just reducing 320->160 or similar the
format doesn't change, just cut off the last bytes. If changing from
higher bandwidth to 20 MHz only EHT STA, adjust the format.
Note that this also requires adjusting the caller in mlme.c since the
data written can now be shorter than it determined. We need to clean
all that up. Since the other callers pass NULL for the conn limit, we
don't need to change things there.
Johannes Berg [Mon, 29 Jan 2024 19:06:54 +0000 (20:06 +0100)]
wifi: mac80211: disallow basic multi-link element in per-STA profile
There really shouldn't be a basic multi-link element in any
per-STA profile in an association response, it's not clear
what that would really mean. Refuse connecting in this case
since the AP isn't following the spec.
Johannes Berg [Mon, 29 Jan 2024 19:06:53 +0000 (20:06 +0100)]
wifi: mac80211: disambiguate element parsing errors
Let the element parsing function return what kind of error
was encountered, as a bitmap, even if nothing currently
checks for which specific error it was, we'll use it later.
Johannes Berg [Mon, 29 Jan 2024 18:34:49 +0000 (19:34 +0100)]
wifi: cfg80211/mac80211: move puncturing into chandef
Aloka originally suggested that puncturing should be part of
the chandef, so that it's treated correctly. At the time, I
disagreed and it ended up not part of the chandef, but I've
now realized that this was wrong. Even for clients, the RX,
and perhaps more importantly, CCA configuration needs to take
puncturing into account.
Move puncturing into the chandef, and adjust all the code
accordingly. Also add a few tests for puncturing in chandef
compatibility checking.
Simplify cfg80211_chandef_compatible() a bit by switching
c1 and c2 around so that c1 is always the narrower one
(once they're not identical or narrow/S1G). Then we can
just check the various primary channels and exit with the
wider one (c2), or NULL.
Also refactor the primary 40/80/160 function to not have
all the calculations hard-coded, and use a wrapper around
it to check primary 40/80/160 compatibility.
While at it, add some kunit tests for this functionality.
Also expose the new cfg80211_chandef_primary_freq() to
drivers, mac80211 will use it.
Add a new inline helper function to ieee80211.h to
extract the disabled subchannels bitmap from an EHT
operation element, and use that in mac80211 where
we do that.
Johannes Berg [Mon, 29 Jan 2024 18:34:44 +0000 (19:34 +0100)]
wifi: cfg80211: move puncturing validation code
Upcoming patches will move the puncturing bitmap into the
chandef, so chandef validation will need to check for correct
puncturing. Purely move the code first so later changes are
easier to review.
Johannes Berg [Mon, 29 Jan 2024 18:34:42 +0000 (19:34 +0100)]
wifi: mac80211: support wider bandwidth OFDMA config
EHT requires that stations are able to participate in
wider bandwidth OFDMA, i.e. parse downlink OFDMA and
uplink OFDMA triggers when they're not capable of (or
not connected at) the (wider) bandwidth that the AP
is using. This requires hardware configuration, since
the entity responsible for parsing (possibly hardware)
needs to know the AP bandwidth.
To support this, change the channel request to have
the AP's bandwidth for clients, and track that in the
channel context in mac80211. This means that the same
chandef might need to be split up into two different
contexts, if the APs are different. Interfaces other
than client are not participating in OFDMA the same
way, so they don't request any AP setting.
Note that this doesn't introduce any API to split a
channel context, so that there are cases where this
might lead to a disconnect, e.g. if there are two
client interfaces using the same channel context, e.g.
both 160 MHz connected to different 320 MHz APs, and
one of the APs switches to 160 MHz.
Note also there are possible cases where this can be
optimised, e.g. when using the upper or lower 160 Mhz,
but I haven't been able to really fully understand the
spec and/or hardware limitations.
If, for some reason, there are no hardware limits on
this because the OFDMA (downlink/trigger) parsing is
done in firmware and can take the transmitter into
account, then drivers can set the new flag
IEEE80211_VIF_IGNORE_OFDMA_WIDER_BW on interfaces to
not have them request any AP bandwidth in the channel
context and ignore this issue entirely. The bss_conf
still contains the AP configuration (if any, i.e. EHT)
in the chanreq.
Johannes Berg [Mon, 29 Jan 2024 18:34:41 +0000 (19:34 +0100)]
wifi: mac80211: add and use a link iteration macro
In the channel context code we have quite a few instances
of nested loops iterating the interfaces and then links.
Add a new for_each_sdata_link() macro and use it. Also,
since it's easier, convert all the loops and a few other
places away from RCU as we now hold the wiphy mutex
everywhere anyway.
This does cause a little bit more work (such as checking
interface types for each link of an interface rather than
not iterating links in some cases), but that's not a huge
issue and seems like an acceptable trade-off, readability
is important too.
Johannes Berg [Mon, 29 Jan 2024 18:34:40 +0000 (19:34 +0100)]
wifi: mac80211: introduce 'channel request'
For channel contexts, mac80211 currently uses the cfg80211
chandef struct (control channel, center freq(s), width) to
define towards drivers and internally how these behave. In
fact, there are _two_ such structs used, where the min_def
can reduce bandwidth according to the stations connected.
Unfortunately, with EHT this is longer be sufficient, at
least not for all hardware. EHT requires that non-AP STAs
that are connected to an AP with a lower bandwidth than it
(the AP) advertises (e.g. 160 MHz STA connected to 320 MHz
AP) still be able to receive downlink OFDMA and respond to
trigger frames for uplink OFDMA that specify the position
and bandwidth for the non-AP STA relative to the channel
the AP is using. Therefore, they need to be aware of this,
and at least for some hardware (e.g. Intel) this awareness
is in the hardware. As a result, use of the "same" channel
may need to be split over two channel contexts where they
differ by the AP being used.
As a first step, introduce a concept of a channel request
('chanreq') for each interface, to control the context it
requests. This step does nothing but reorganise the code,
so that later the AP's chandef can be added to the request
in order to handle the EHT case described above.
Johannes Berg [Mon, 29 Jan 2024 18:34:38 +0000 (19:34 +0100)]
wifi: mac80211: simplify non-chanctx drivers
There are still surprisingly many non-chanctx drivers, but in
mac80211 that code is a bit awkward. Simplify this by having
those drivers assign 'emulated' ops, so that the mac80211 code
can be more unified between non-chanctx/chanctx drivers. This
cuts the number of places caring about it by about 15, which
are scattered across - now they're fewer and no longer in the
channel context handling.
Johannes Berg [Mon, 29 Jan 2024 18:34:37 +0000 (19:34 +0100)]
wifi: mac80211: clean up HE 6 GHz and EHT chandef parsing
In the code we currently check for support 80+80, 160
and 320 channel widths, but really the way this should
be (and is otherwise) handled is that we compute the
highest channel bandwidth given there, and then cut it
down to what we support. This is also needed for wider
bandwidth OFDMA support.
Change the code to remove this limitation and always
parse the highest possible channel width.
Johannes Berg [Mon, 29 Jan 2024 18:34:36 +0000 (19:34 +0100)]
wifi: mac80211: clean up connection process
Rewrite the station-side connection handling. The connection
flags (IEEE80211_DISABLE_*) are rather confusing, and they're
not always maintained well. Additionally, for wider-bandwidth
OFDMA support we need to know the precise bandwidth of the AP,
which is currently somewhat difficult.
Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit
on the bandwidth. This is not entirely clean because some of
those modes aren't completely sequenced (as this assumes in
some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does.
However, it still simplifies things and gives us a good idea
what we're operating as, so we can parse elements accordingly
etc.
This leaves a FIXME for puncturing, this is addressed in a
later patch.
Johannes Berg [Mon, 29 Jan 2024 18:34:35 +0000 (19:34 +0100)]
wifi: mac80211: clean up band switch in duration
Most devices now do duration calculations, so we don't hit
this code at all any more. Clearly the approach of warning
at compile time here when new bands are added didn't work,
the new bands were just added with "TODO". Clean it up, it
won't matter for new bands since they'll just not have any
need to calculate durations in software.
While at it, also clean up and unify the code a bit.
Johannes Berg [Wed, 31 Jan 2024 15:49:04 +0000 (16:49 +0100)]
wifi: mac80211: remove extra shadowing variable
Not sure how this happened or how nothing complained, but
this variable already exists in the outer function scope
with the same value (and the SKB isn't changed either.)
Remove the extra one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Thu, 8 Feb 2024 08:57:43 +0000 (09:57 +0100)]
Merge wireless into wireless-next
There are some changes coming to wireless-next that will
otherwise cause conflicts, pull wireless in first to be
able to resolve that when applying the individual changes
rather than having to do merge resolution later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Martin Kaistra [Mon, 5 Feb 2024 09:30:40 +0000 (10:30 +0100)]
wifi: rtl8xxxu: update rate mask per sta
Until now, rtl8xxxu_watchdog_callback() only fetches RSSI and updates
the rate mask in station mode. This means, in AP mode only the default
rate mask is used.
In order to have the rate mask reflect the actual connection quality,
extend rtl8xxxu_watchdog_callback() to iterate over every sta. Like in
the rtw88 driver, add a function to collect all currently present stas
and then iterate over a list of copies to ensure no RCU lock problems
for register access via USB. Remove the existing RCU lock in
rtl8xxxu_refresh_rate_mask().
Since the currently used ieee80211_ave_rssi() is only for 'vif', add
driver-level tracking of RSSI per sta.
Now that the driver core can properly handle constant struct bus_type,
move the bcma_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204-bus_cleanup-bcma-v1-1-0d881c793190@marliere.net
Now that the driver core can properly handle constant struct bus_type,
move the ssb_bustype variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240204-bus_cleanup-ssb-v1-1-511026cd5f3c@marliere.net
However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy.
Reported-by: Ulrich Mohr <u.mohr@semex-engcon.com> Co-developed-by: Ulrich Mohr <u.mohr@semex-engcon.com> Signed-off-by: Ulrich Mohr <u.mohr@semex-engcon.com> Fixes: 268bceec1684 ("staging: wfx: fix BA when device is AP and MFP is enabled") Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202164213.1606145-1-jerome.pouiller@silabs.com
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:27 +0000 (09:26 +0800)]
wifi: rtw89: fw: download firmware with key data for secure boot
Since firmware header contains multiple secure sections, we need to trim
ignored sections, and then download firmware header with single one secure
section.
For secure boot, when downloading secure section, copy security key data
from MSS poll by key_idx read from efuse. If non-secure boot, no need this
extra copy.
+---------------------------+ -\
| firmware header | |
| | |
| +-----------------------+ | | only preserve single one secure
| | section type/size * N | | | section
| | ... | | |
| +-----------------------+ | |
+---------------------------+ -/
: :
+---------------------------+ -\
| secure section type (ID:9)| |
| | |
+----|-> [ security key data ] | |
| +---------------------------+ -/
| |MSS Pool for above section |
| | [ security key data 0 ] |
+----|- [ security key data 1 ] |
by key_idx | [ security key data 2 ] |
| ... |
+---------------------------+
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:26 +0000 (09:26 +0800)]
wifi: rtw89: fw: parse secure section from firmware file
A firmware file can contains more than one section with secure type, so
use secure information from efuse to choose the one with matched
cryptography method. Then choose key data from MSS poll (multiple security
section pool; see below picture) according to key_index from efuse.
Note that the size of MSS pool isn't included in section size defined
in firmware header, so we also need to parse header of MSS pool to get
its size as shift to parse next section.
If secure boot isn't supported by current hardware, the first secure
section will be adopted, and no need additional process to key data.
Ping-Ke Shih [Sun, 4 Feb 2024 01:26:25 +0000 (09:26 +0800)]
wifi: rtw89: fw: read firmware secure information from efuse
To support firmware secure boot, read secure information from efuse to
know if current hardware module can support secure boot with certain
cryptography method.
This information should be prepared before downloading firmware, so read
efuse right after power on at probe stage. The secure information includes
secure cryptography method and secure key index that are used to choose
proper key material when downloading firmware.
projects / thirdparty / kernel / linux.git / log
