clang reports uninitialized use:

>> drivers/net/wireless/realtek/rtw88/main.c:731:2: warning: variable
   'primary_channel_idx' is used uninitialized whenever switch default is
   taken [-Wsometimes-uninitialized]
           default:
           ^~~~~~~
   drivers/net/wireless/realtek/rtw88/main.c:754:39: note: uninitialized
   use occurs here
           hal->current_primary_channel_index = primary_channel_idx;
                                                ^~~~~~~~~~~~~~~~~~~
   drivers/net/wireless/realtek/rtw88/main.c:687:24: note: initialize the
   variable 'primary_channel_idx' to silence this warning
           u8 primary_channel_idx;
                                 ^
                                  = '\0'

This situation could not happen, because possible channel bandwidth
20/40/80MHz are enumerated.

Fixes: 341dd1f7 ("wifi: rtw88: add the update channel flow to support setting by parameters")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20220815062004.22920-1-pkshih@realtek.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The full 'unsigned int' is better than 'unsigned'.
Signed-off-by: NXin Gao <gaoxin@cdjrlc.com>
Link: https://lore.kernel.org/r/20220816181040.9044-1-gaoxin@cdjrlc.com
[fix indentation]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Driver may update sinfo directly through .sta_statistics, so this
patch makes sure that ethool gets the correct statistics.
Signed-off-by: NRyder Lee <ryder.lee@mediatek.com>
Link: https://lore.kernel.org/r/f9edff14dd7f5205acf1c21bae8e9d8f9802dd88.1661466499.git.ryder.lee@mediatek.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

If we add 6 GHz capability in MLO, we cannot use the SMPS
mode from the deflink. Pass it separately instead since on
a second link we don't even have a link data struct yet.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add link_id parameter to cfg80211_ch_switch_started_notify() to allow
driver to indicate on which link channel switch started on MLD.

Send the data to userspace so it knows as well.
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220722131143.3438042-1-quic_vjakkam@quicinc.com
Link: https://lore.kernel.org/r/20220722131143.3438042-2-quic_vjakkam@quicinc.com
[squash two patches]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, MLO link level channel information not sent to
userspace when NL80211_CMD_GET_INTERFACE requested on MLD.

Add support to send channel information for all valid links
for NL80211_CMD_GET_INTERFACE request.
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220722131000.3437894-1-quic_vjakkam@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

From 'IEEE Std 802.11-2020 section 11.8.8.4.1':
  The mesh channel switch may be triggered by the need to avoid
  interference to a detected radar signal, or to reassign mesh STA
  channels to ensure the MBSS connectivity.

  A 20/40 MHz MBSS may be changed to a 20 MHz MBSS and a 20 MHz
  MBSS may be changed to a 20/40 MHz MBSS.

Since the standard allows the change of bandwidth during
the channel switch in mesh, remove the bandwidth check present in
ieee80211_set_csa_beacon.

Fixes: c6da674a ("{nl,cfg,mac}80211: enable the triggering of CSA frame in mesh")
Signed-off-by: NHari Chandrakanthan <quic_haric@quicinc.com>
Link: https://lore.kernel.org/r/1658903549-21218-1-git-send-email-quic_haric@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit 177577db ("wifi: mac80211: sta_info: fix link_sta insertion")
makes ieee80211_sta_activate_link() return 0 in the 'hash' label case.
Hence, setting ret in the !test_sta_flag(...) branch to zero is not needed
anymore and can be dropped.

Remove a needless assignment.

No functional change. No change in object code.
Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220812103126.25308-1-lukas.bulwahn@gmail.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

In ieee80211_tx_dequeue() we currently allow a control port
frame to be transmitted on a non-authorized port only if the
A2 matches the local interface address, but if that's an MLD
and the peer is a legacy peer, we need to allow link address
here. Fix that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For an AP interface, when userspace specifieds the link ID to
transmit the control port frame on (in particular for the
initial 4-way-HS), due to the logic in ieee80211_build_hdr()
for a frame transmitted from/to an MLD, we currently build a
header with

 A1 = DA = MLD address of the peer MLD
 A2 = local link address (!)
 A3 = SA = local MLD address

This clearly makes no sense, and leads to two problems:
 - if the frame were encrypted (not true for the initial
   4-way-HS) the AAD would be calculated incorrectly
 - if iTXQs are used, the frame is dropped by logic in
   ieee80211_tx_dequeue()

Fix the addressing, which fixes the first bullet, and the
second bullet for peer MLDs, I'll fix the second one for
non-MLD peers separately.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is simple here, and might save drivers some work if
they have common code for TX between beacons and other
frames.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The code for determining which links to update in wmediumd
or virtio was wrong, fix it to remove the deflink only if
there were no old links, and also add the deflink if there
are no other new links.

Fixes: c204d9df ("wifi: mac80211_hwsim: handle links for wmediumd/virtio")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To helper drivers if they e.g. have a lookup of the link_sta
pointer, add the link ID to the link_sta structure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For AP/non-AP the EHT MCS/NSS subfield size differs, the
4-octet subfield is only used for 20 MHz-only non-AP STA.
Pass an argument around everywhere to be able to parse it
properly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The next patch will require splitting the data here into
AP and non-AP because for EHT, the format of the MCS/NSS
support (struct ieee80211_eht_mcs_nss_supp) is different,
for AP the only_20mhz cannot be used.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Draft P802.11be_D2.1, section 35.3.17 states that the EML Capabilities
Field shouldn't be included in case the device doesn't have support for
EMLSR or EMLMR.

Fixes: 81151ce4 ("wifi: mac80211: support MLO authentication/association with one link")
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When queuing frames to an interface store the link ID we
determined (which possibly came from the driver in the
RX status in the first place) in the RX status, and use
it in the MLME code to send probe responses, beacons and
CSA frames to the right link.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

With link_id reported in rx_status for MLO connection, do the
stats update on the appropriate link instead of always deflink.
Signed-off-by: NVasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
Link: https://lore.kernel.org/r/20220817104213.2531-3-quic_vthiagar@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

In MLO, when the address translation from link to MLD is done
in fw/hw, it is necessary to be able to have some information
on the link on which the frame has been received. Extend the
rx API to include link_id and a valid flag in ieee80211_rx_status.
Also make chanes to mac80211 rx APIs to make use of the reported
link_id after sanity checks.
Signed-off-by: NVasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
Link: https://lore.kernel.org/r/20220817104213.2531-2-quic_vthiagar@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Implement key installation and lookup (on TX and RX)
for MLO, so we can use multiple GTKs/IGTKs/BIGTKs.
Co-authored-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add support for various key operations on MLD by adding new parameter
link_id. Pass the link_id received from userspace to driver for add_key,
get_key, del_key, set_default_key, set_default_mgmt_key and
set_default_beacon_key to support configuring keys specific to each MLO
link. Userspace must not specify link ID for MLO pairwise key since it
is common for all the MLO links.
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220730052643.1959111-4-quic_vjakkam@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently, MLO support is not added for WEXT code and WEXT handlers are
prevented on MLDs. Prevent WEXT handler cfg80211_wext_siwencodeext()
also on MLD which is missed in commit 7b0a0e3c ("wifi: cfg80211: do
some rework towards MLO link APIs")
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220730052643.1959111-3-quic_vjakkam@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

MLO connections are not supposed to use WEP security. Reject connect
response of MLO connection if WEP security mode is used.
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20220730052643.1959111-2-quic_vjakkam@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

We've already freed the assoc_data at this point, so need
to use another copy of the AP (MLD) address instead.

Fixes: 81151ce4 ("wifi: mac80211: support MLO authentication/association with one link")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Configure the correct link per the passed parameters.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The Tx queue parameters are per link, so add the link ID
from nl80211 parameters to the API.

While at it, lock the wdev when calling into the driver
so it (and we) can check the link ID appropriately.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For an AP interface, set the link BSSID when the link
is initialized.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When checking for channel regulatory validity, use the
AP link chandef (and not mesh's chandef).

Fixes: 7b0a0e3c ("wifi: cfg80211: do some rework towards MLO link APIs")
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Based on changes in the specification the TBTT information in
the RNR can include MLD information, so update the parsing to
allow extracting the short SSID information in such a case.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In ieee80211_sta_remove_link, valid_links is set to
the new_links before calling drv_change_sta_links, but
is used for the old_links.

Fixes: cb71f1d1 ("wifi: mac80211: add sta link addition/removal")
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If there's no link ID, then check that there are no changes to
the link, and if so accept them, unless a new link is created.
While at it, reject creating a new link without an address.

This fixes authorizing an MLD (peer) that has no link 0.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Mac80211 core may ask driver to change to idle mode during HW scan,
then H2C command for HW scan will send failed since chip is in idle
mode. Therefore, We check the SCANNING flag before entering IPS to
prevent this behavior.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-8-pkshih@realtek.com

Enter or leave IPS controlled by mac80211 before driver support HW
scan. After support HW scan, driver need to control IPS before start
HW scan and scan complete, but mac80211 also ask driver enter or leave
IPS. Therefore, we add flag check in IPS to prevent entering or
leaving IPS twice.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-7-pkshih@realtek.com

We need to flush queue before HW scan to avoid packets dropped by hardware.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-6-pkshih@realtek.com

During HW scan, the channel related feilds in hal struct changed partially.
If setting Tx power will get WARNING:rtw_get_tx_power_params() due to some
of fields in hal struct mismatch. Therefore, we fix to change all required
fields in hal struct when channel switch during HW scan.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-5-pkshih@realtek.com

In order to set channel info to hal during HW scan, we add the update
channel flow to support setting by parameters to meet the HW scan
requriement.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-4-pkshih@realtek.com

Applying regulatory and getting Tx power table will access hal
data, it should hold rtwdev::mutex to avoid hal data changed during
setting flow.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-3-pkshih@realtek.com

Applying SAR will access hal data, it should hold rtwdev::mutex
to avoid hal data changed during setting flow.
Signed-off-by: NChih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809084107.38137-2-pkshih@realtek.com

The skb will be allocated to send TIM update info in brcmf_fws_tim_update.
Currently the skb will be freed when tx is failed but it will not be freed
when tx is completed successfully. The fix is to free the skb when tx is
completed always.
Signed-off-by: NWataru Gohda <wataru.gohda@cypress.com>
Signed-off-by: NChi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220722115632.620681-6-alvin@pqrs.dk