wifi: iwlwifi: mvm: Stop processing MCC update if there was no change

When processing a MCC update notification from the firmware, if
the firmware indicates that the regulatory configuration didn't
change, abort the flow and do not notify higher layers.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.60dd273d00e0.I985b3bc61ca4a6cac7c1d1365b5c0afba04f3031@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: add API for EML OMN frame failure

When the firmware fails to send EML OMN frames, it notifies the host and
the host need to take proper action.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.0c6bc216ef8c.Ida85d2062734a569e1af35f47d14cc5bb4bf893e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: exit EMLSR if both links are missing beacons

If both links are missing 5 beacons, we need to exit EMLSR, if only one
link misses beacons, we need to wait until 11 beacons are missed.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.b7785943a4fe.I70a459c5e7db85f398d5795ba83bb15f65d6bf9d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: handle the new missed beacons notification

Use the same handler for both types and just convert the old version to
the new. Drop the unused fields from the old one and fake the new
fields.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.a64ffc998569.I7d181052b1a69c331d07263f20c1e00cbc0bc891@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: add the new API for the missed beacons notification

Note that the new API does not have the same notification ID as the
previous notification: the new notification belongs to the group 0x3.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.4ea52360b32e.Ibc25dcabd8aeadda906549482a6c77bc42fb55bb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: rename iwl_missed_beacons_notif

A new version is coming up. Rename the current struct to include the
current version.

s/iwl_missed_beacons_notif/iwl_missed_beacons_notif_v4

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.b5c3a83a05ef.I698611582b5ca8395f42a535c51f7230307e2c6f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: Offload RLC/SMPS functionality to firmware

Currently, the driver handles SMPS decisions by tracking AP
capabilities, BT coexistence changes, sending necessary SMPS
frames to the AP, and updating firmware with RX chain info
using the RLC_CONFIG_CMD.

Starting with version 3 of the RLC_CONFIG_CMD, the firmware
takes over this responsibility. It now tracks SMPS, sends
frames, and configures the RLC.

In this patch:
1. Stop sending RLC_CONFIG_CMD when firmware supports RLC
   offload (version 3), as rlc.rx_chain_info is not needed by
   firmware, and no other field in the cmd is used.
2. Prevent the driver from forwarding any SMPS requests to
   mac80211, i.e., the driver should not transmit SMPS frames
   to the AP as firmware handles that.
3. Set NL80211_FEATURE_DYNAMIC_SMPS and NL80211_FEATURE_STATIC_SMPS
   conditionally based on RLC version.

Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.45da23be1f65.I0d46db82dd990a82e8a66876fe2f5310bc9513be@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: fix the comeback long retry times

When we had a comeback, we will never use the default timeout values
again because comeback is never cleared.
Clear comeback if we send another association request which will allow
to start a default timer after Tx status.

The problem was seen with iwlwifi where the tx_status on the association
request is handled before the association response frame (which is the
usual case).

1) Tx assoc request 1/3
2) Rx assoc response (comeback, timeout = 1 second)
3) wait 1 second
4) Tx assoc request 2/3
5) Set timer to IEEE80211_ASSOC_TIMEOUT_LONG = 500ms (1 second after
   round_up)
6) tx_status on frame sent in 4) is ignored because comeback is still
   true
7) AP does not reply with assoc response
8) wait 1s <= This is where the bug is felt
9) Tx assoc request 3/3

With this fix, in step 6 we will reset the timer to
IEEE80211_ASSOC_TIMEOUT_SHORT = 100ms and we will wait only 100ms in
step 8.

Fixes: b133fdf07db8 ("wifi: mac80211: Skip association timeout update after comeback rejection")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20240808085916.23519-1-emmanuel.grumbach@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority

According to RFC8325 4.3, Multimedia Streaming: AF31(011010, 26),
AF32(011100, 28), AF33(011110, 30) maps to User Priority = 4
and AC_VI (Video).

However, the original code remain the default three Most Significant
Bits (MSBs) of the DSCP, which makes AF3x map to User Priority = 3
and AC_BE (Best Effort).

Fixes: 6fdb8b8781d5 ("wifi: cfg80211: Update the default DSCP-to-UP mapping")
Signed-off-by: hhorace <hhoracehsu@gmail.com>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20240807082205.1369-1-hhoracehsu@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: Add non-atomic station iterator

Drivers may at times want to iterate their stations with a function
which requires some non-atomic operations.

ieee80211_iterate_stations_mtx() introduces an API to iterate stations
while holding that wiphy's mutex. This allows the iterating function to
do non-atomic operations safely.

Signed-off-by: Rory Little <rory@candelatech.com>
Link: https://patch.msgid.link/20240806004024.2014080-2-rory@candelatech.com
[unify internal list iteration functions]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

staging: rtl8192e: Constify struct lib80211_crypto_ops

Now that functions in lib80211 handle "const struct lib80211_crypto_ops",
some structure can be constified as well.

Constifying these structures moves some data to a read-only section, so
increase overall security.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/dfda6343781ae3d50cd2ec7bbdcf76a489b6922a.1722839425.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: lib80211: Constify struct lib80211_crypto_ops

Now that functions in lib80211 handle "const struct lib80211_crypto_ops",
some structure can be constified as well.

Constifying these structures moves some data to a read-only section, so
increase overall security.

Before:
   text    data     bss     dec     hex filename
   7273     604      16    7893    1ed5 net/wireless/lib80211.o

After:
   text    data     bss     dec     hex filename
   7429     444      16    7889    1ed1 net/wireless/lib80211.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/0cc3741c15f2c502cc85bddda9d6582b5977c8f9.1722839425.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: lib80211: Handle const struct lib80211_crypto_ops in lib80211

lib80211_register_crypto_ops() and lib80211_unregister_crypto_ops() don't
modify their "struct lib80211_crypto_ops *ops" argument. So, it can be
declared as const.

Doing so, some adjustments are needed to also constify some date in
"struct lib80211_crypt_data", "struct lib80211_crypto_alg" and the
return value of lib80211_get_crypto_ops().

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/c74085e02f33a11327582b19c9f51c3236e85ae2.1722839425.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: add and improve EMLSR debug info

Add prints of the per-link MPDU counters, and change the other MPDU
counters related prints to use DL_INFO, which is already used for all
EMLSR tests anyway, instead of DL_STATS which pollutes the logs with all
the RX signal info.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Daniel Gabay <daniel.gabay@intel.com>
Link: https://patch.msgid.link/20240729201718.02bd85837c87.I85480c9c4fab0f7a574dd69cbeafd82674146921@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: Enable channel puncturing for US/CAN from bios

Add support for enabling channel puncturing for US/CAN based
on BIOS configuration through UEFI

Signed-off-by: Somashekhar(Som) <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.828f3ecf5118.I5561ab8c7cd48ad4e5d6daf21b037bf88c619a4a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: add firmware debug points for EMLSR entry / exit

This will help to dump the firmware logs at the right spot if needed.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.3a91e89e32f8.Ieb28d7756c47dee52c912a71abe82fa0b08b19da@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwiif: mvm: handle the new BT notif

Iterate all the links and check if any action must be taken.
The new notification impacts only the esr decision.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.00cfc07879c6.I8491483fda3b5888ea6ffa10fbd17807e443f943@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: start to support the new BT profile notification

We have a new notification the BT profile. It contains almost nothing,
only the wifi loss information. Copy this into mvm. We still need to
iterate over the vifs / links to use this data.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.637499f3a85a.I8bf654cf5d8aa038100273876c936845ecc338f7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: s/iwl_bt_coex_profile_notif/iwl_bt_coex_prof_old_notif

The iwl_bt_coex_profile_notif is now being obsoleted. It'll be replaced
by a new notification coming with a non-legacy group. Rename it to avoid
confusion.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.dc29fd0d7817.I5881fce86ec8b76ae98d2948265434b8e7d860c1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: increase the time between ranging measurements

The algo running in fw may take a little longer than 5 milliseconds,
(e.g. measurement on 80MHz while associated). Increase the minimum
time between measurements to 7 milliseconds.

Fixes: 830aa3e7d1ca ("iwlwifi: mvm: add support for range request command version 13")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.d3f3c26e00d9.I09e951290e8a3d73f147b88166fd9a678d1d69ed@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: set the cipher for secured NDP ranging

The cipher pointer is not set, but is derefereced trying to set its
content, which leads to a NULL pointer dereference.
Fix it by pointing to the cipher parameter before dereferencing.

Fixes: 626be4bf99f6 ("wifi: iwlwifi: mvm: modify iwl_mvm_ftm_set_secured_ranging() parameters")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.24e83369f136.I80501ddcb82920561f450d00020d860e7a3f90c6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: Fix a race in scan abort flow

When the upper layer requests to cancel an ongoing scan, a race
is possible in which by the time the driver starts to handle the
upper layers scan cancel flow, the FW already completed handling
the scan request and the driver received the scan complete
notification but still did not handle the notification. In such a
case the FW will simply ignore the scan abort request coming from
the driver, no notification would arrive from the FW and the entire
abort flow would be considered a failure.

To better handle this, check the status code returned by the FW for
the scan abort command. In case the status indicates that
no scan was aborted, complete the scan abort flow with success, i.e.,
the scan was aborted, as the flow is expected to consume the scan
complete notification.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825085558.483989d3baef.I3340556a222388504c6330b333360bf77d10f9e2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: set ul_mu_data_disable when needed

The firmware needs to know what we had in the HE CAP, propagate that
setting to the firmware through the LINK command.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.fef270d2995b.I328237837df30e1cb98764987eaaf8e8993e058c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mei: add support for SAP version 4

SAP version 4 uses larger Host to MEI notification queue.
Since it is unknown which SAP version is used by the CSME firmware
when the driver loads, try version 4 first. In case the CSME firmware
uses version 3, the memory allocation will fail. In this case the
driver will try again to allocate the memory for version 3.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.8372e040282f.Ia0085784e08a35159c9293f986c3d2774038f4c4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: config: label 'gl' devices as discrete

The 'gl' devices are in the bz family, but they're not,
integrated, so should have their own trans config struct.
Fix that, also necessitating the removal of LTR config,
and while at it remove 0x2727 and 0x272D IDs that were
only used for test chips.

Fixes: c30a2a64788b ("wifi: iwlwifi: add a new PCI device ID for BZ device")ticket=none
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.95aed0620080.Ib9129512c95aa57acc9876bdff8b99dd41e1562c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: pcie: print function scratch before writing

We may want to know the value of this register for certain
debug scenarios before we overwrite it, it indicates which
parts of the chip have recently been reset.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.737e5f8bb8df.Ia3f3637ac4a0fb4b35ffd652f92eb75de652ee12@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: use correct key iteration

In the cases changed here, key iteration isn't done from
an RCU critical section, but rather using the wiphy lock
as protection. Therefore, just use ieee80211_iter_keys().
The link switch case can therefore also use sync commands.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.69a2d18580c1.I2148e04d4b467d0b100beac8f7e449bfaaf775a5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: remove MVM prefix from FW macros

These are not mvm specific.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20240729201718.939b32f84f46.I293957bf172680871eba24448d9d1870e49100b6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: add support for new REDUCE_TXPOWER_CMD versions

New API versions are coming up for this command.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.7ec1527be98c.I52dede6532bc61041c441caee5273734f14a1d78@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: prepare the introduction of V9 of REDUCED_TX_POWER

* Rename iwl_dev_tx_power_cmd to iwl_dev_tx_power_cmd_v3_v8
* struct iwl_dev_tx_power_common needs to be packed. It was always the
  case, but now that its size is not a multiple of 4, it becomes
  meaningful.
* Move per_band data out of the common structure since it won't be
  present in the new versions of the command.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.8da29a66984f.I922bdef4740d990f98cb452e858c4157bbc491c5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: don't use rate mask for offchannel TX either

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for
scanning"), ignore incorrect settings to avoid no supported rate warning
reported by syzbot.

The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:
fix default HE tx bitrate mask in 2G band"), which however corrects
bitmask of HE MCS and recognizes correctly settings of empty legacy rate
plus HE MCS rate instead of returning -EINVAL.

As suggestions [1], follow the change of SCAN TX to consider this case of
offchannel TX as well.

[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

Reported-by: syzbot+8dd98a9e98ee28dc484a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-wireless/000000000000fdef8706191a3f7b@google.com/
Fixes: 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240729074816.20323-1-pkshih@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: refactor block ack management code

Introduce 'ieee80211_mgmt_ba()' to avoid code duplication between
'ieee80211_send_addba_resp()', 'ieee80211_send_addba_request()',
and 'ieee80211_send_delba()', ensure that all related addresses
are '__aligned(2)', and prefer convenient 'ether_addr_copy()'
over generic 'memcpy()'. No functional changes expected.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://patch.msgid.link/20240725090925.6022-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio

Correct the name field in multi_radio's MODULE_PARM_DESC.

Fixes: d2601e34a102 ("wifi: mac80211_hwsim: add support for multi-radio wiphy")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
Link: https://patch.msgid.link/20240712074938.26437-1-kevin_yang@realtek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: remove unnecessary checks for valid priv

The pointers in adapter->priv[] are allocated in mwifiex_register().
With an allocation failed the function will return an error and
driver initialization is aborted. This makes all checks for valid
priv pointers unnecessary throughout the driver. In many places
the pointers are assumed to be valid without checks, this patch
removes the remaining checks.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240816-mwifiex-remove-priv-checks-v1-1-6dd6553e8ed9@pengutronix.de

wifi: mwifiex: Fix uninitialized variable in mwifiex_cfg80211_authenticate()

Smatch complains that:

    drivers/net/wireless/marvell/mwifiex/cfg80211.c:4408 mwifiex_cfg80211_authenticate()
    error: uninitialized symbol 'varptr'.

It's a check for NULL, but "varptr" is either non-NULL or uninitialized.
Initialize it to NULL.

Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/d7d043b2-95d5-4e1d-b340-5d7330053ac6@stanley.mountain

wifi: iwlegacy: Avoid multiple -Wflex-array-member-not-at-end warnings

-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.

So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `__struct_group()`
helper to create new tagged structures with the suffix `_hdr`.
These structures group together all the members of the original
flexible structures except the flexible arrays.

As a result, the arrays are effectively separated from the rest of the
members without modifying the memory layout of the flexible structures.
We then change the type of the middle struct members currently causing
trouble from the original flex struct to the newly created structs with
suffix `_hdr`.

We also want to ensure that when new members need to be added to the
flexible structures, they are always included within the newly created
tagged structs. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.

This approach avoids having to implement the `_hdr` structures as
completely separate structures, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.

We also use `container_of()` whenever we need to retrieve a pointer to
the flexible structure, through which we can access the flexible-array
member, if necessary.

Also, remove a couple of unused zero-length arrays and flexible-array
members.

So, with these changes, fix the following warnings:

drivers/net/wireless/intel/iwlegacy/commands.h:1196:38: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:1197:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2505:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2549:26: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2654:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2665:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:2673:26: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/iwlegacy/commands.h:3349:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/Zr2gxERA3RL3EwRe@elsanto

wifi: mwifiex: keep mwifiex_cfg80211_ops constant

With host_mlme support being added mwifiex_cfg80211_ops is no longer
constant, but supplemented with the host_mlme related ops when host_mlme
support is enabled. This doesn't work with multiple adapters when only
few of then have host_mlme support. Duplicate mwifiex_cfg80211_ops
before using it and keep the original constant.

While at it mark mwifiex_cfg80211_ops const to prevent people from
changing it again during runtime.

Fixes: 36995892c271c ("wifi: mwifiex: add host mlme for client mode")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240809-mwifiex-duplicate-mwifiex_cfg80211_ops-v1-1-23e0e6290ace@pengutronix.de

Merge tag 'ath-next-20240812' of git://git./linux/kernel/git/ath/ath

ath.git patches for v6.12

This is a fairly light pull request since ath12k is still working on
MLO-related changes, and the other drivers are mostly in maintenance
mode with a few cleanups and bug fixes.

Major changes:

ath12k

* DebugFS support for transmit DE stats
* Make ASPM support hardware-dependent
* Align BSS Channel information command and message with firmware

ath11k

* Use work queue for beacon tx events

ath9k

* Use devm for gpio_request_one
* Use unmanaged PCI functions in ath9k_pci_owl_loader()

wifi: mwl8k: Use static_assert() to check struct sizes

Commit 5c4250092fad ("wifi: mwl8k: Avoid -Wflex-array-member-not-at-end
warnings") introduced tagged `struct mwl8k_cmd_pkt_hdr`. We want to
ensure that when new members need to be added to the flexible structure,
they are always included within this tagged struct.

We use `static_assert()` to ensure that the memory layout for both
the flexible structure and the tagged struct is the same after any
changes.

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/ZrVCg51Q9M2fTPaF@cute

Merge tag 'rtw-next-2024-08-09' of https://github.com/pkshih/rtw

rtw-next patches for v6.12

A pull-request for v6.12 containing fixes and features, and list major
changes below:

rtw88:
 - improve USB performance by aggregation
 - fix RX bandwidth for rx_status

rtw89:
 - support new WiFi 6 chip RTL8852BE-VT
 - support WoWLAN net-detect feature
 - support hardware encryption in unicast management frames
 - support hardware rfkill

wifi: ipw2x00: libipw: Avoid -Wflex-array-member-not-at-end warnings

-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.

So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `__struct_group()`
helper to create a new tagged `struct libipw_hdr_3addr_hdr`.
This structure groups together all the members of the flexible
`struct libipw_hdr_3addr` except the flexible array.

As a result, the array is effectively separated from the rest of the
members without modifying the memory layout of the flexible structure.
We then change the type of the middle struct members currently causing
trouble from `struct libipw_hdr_3addr` to `struct libipw_hdr_3addr_hdr`.

We also want to ensure that when new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.

This approach avoids having to implement `struct libipw_hdr_3addr_hdr`
as a completely separate structure, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.

Also, remove a couple of unused structures `struct libipw_ibss_dfs` and
`struct libipw_assoc_request`.

So, with these changes, fix the following warnings:

drivers/net/wireless/intel/ipw2x00/libipw.h:403:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:420:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:433:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:441:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:447:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:460:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:468:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:476:33: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:592:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/ZrJqtUpCI+uCeb4D@cute

wifi: mwifiex: add support for WPA-PSK-SHA256

This adds support for the WPA-PSK AKM suite with SHA256 as hashing
method (WPA-PSK-SHA256). Tested with a wpa_supplicant provided AP
using key_mgmt=WPA-PSK-SHA256.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240717-mwifiex-wpa-psk-sha256-v2-2-eb53d5082b62@pengutronix.de
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20240723-mwifiex-wpa-psk-sha256-v3-3-025168a91da1@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240805-mwifiex-wpa-psk-sha256-v4-3-e1eee80508e6@pengutronix.de

wifi: mwifiex: fix key_mgmt setting

bss_config->key_mgmt specifies the AKM suites that are usable in
hardware. This variable is set to specific values while iterating
over the advertised AKM suites. This means the final value of the
variable depends on the order of the entries in the AKM suites
array. Instead of setting the variable, just set the relevant bits
in the key_mgmt bit field to make us independent of the order of
entries.
This behaviour is derived from the downstream driver that does the
same.
Also, set bss_config->key_mgmt to zero explicitly right before the
loop. bss_config has been zero allocated by the caller already, but
do so again to save the reader from following the code path.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20240723-mwifiex-wpa-psk-sha256-v3-2-025168a91da1@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240805-mwifiex-wpa-psk-sha256-v4-2-e1eee80508e6@pengutronix.de

wifi: mwifiex: simplify WPA flags setting

The WPA flags setting only depends on the wpa_versions bitfield and not
on the AKM suite, so move it out of the switch/case to simplify the code
a bit. Also set bss_config->protocol to zero explicitly. This is done
only to make the code clearer, bss_config has been zero alloced by the
caller, so should be zero already. No functional change intended.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20240723-mwifiex-wpa-psk-sha256-v3-1-025168a91da1@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240805-mwifiex-wpa-psk-sha256-v4-1-e1eee80508e6@pengutronix.de

Revert "wifi: ath9k: use devm for request_irq()"

This reverts commit 92da4ce847bc5d942ddfdb102dba92f4e2797a59.

Felix pointed out that moving to devm for request_irq() can lead to a use after
free, and that avoiding that means having explicit frees that makes the devm
thing pretty pointless. So let's just revert the patch.

Link: https://lore.kernel.org/r/201f06b6-14f5-41bb-8897-49665cf14b66@nbd.name
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240808103758.11696-1-toke@toke.dk

wifi: rtw88: Enable USB RX aggregation for 8822c/8822b/8821c

Enable USB RX aggregation when there is at least 1 Mbps RX or TX
traffic, otherwise disable it.

USB RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. Before: 28 Mbps, after: 231 Mbps.

It also improves the RX speed of RTL8822CU on some x86_64 systems.
Before: ~200 Mbps, after: ~300 Mbps.

The official drivers for these chips use the same logic for SDIO, but
for some reason the SDIO driver in rtw88 always enables RX aggregation,
so this patch only toggles aggregation for USB devices.

RTL8703B is likely not found in USB devices, and RTL8723DU doesn't like
aggregation.

Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/b4c0d54c-6755-4b0f-9dd7-f9196fd74b68@gmail.com

wifi: rtw88: usb: Support RX aggregation

The chips can be configured to aggregate several frames into a single
USB transfer. Modify rtw_usb_rx_handler() to support this case.

RX aggregation improves the RX speed of RTL8811CU on certain ARM
systems, like the NanoPi NEO Core2. It also improves the RX speed of
RTL8822CU on some x86_64 systems.

Currently none of the chips are configured to aggregate frames.

Tested with RTL8822CU, RTL8811CU, and RTL8723DU.

Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f845826d-de71-492d-9a22-e48c07989a1f@gmail.com

wifi: rtw88: usb: Update the RX stats after every frame

Update the number of received unicast data frames and bytes every time
a frame is received. This is what the PCI and SDIO drivers do.

This has an influence on the power saving, bluetooth coexistence, and
(in a future patch) the use of RX aggregation.

Tested with RTL8822CU, RTL8811CU, and RTL8723DU.

Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com

wifi: rtw88: usb: Init RX burst length according to USB speed

This is needed in order to make USB RX aggregation work with RTL8811CU
(and presumably RTL8822BU and RTL8822CU also).

I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN
are doing.

Tested with RTL8822CU, RTL8811CU, and RTL8723DU.

The RX speed is unchanged in my tests.

Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com

wifi: rtl8xxxu: add missing rtl8192cu USB IDs

The rtl8xxxu has all the rtl8192cu USB IDs except for the
following 3 so add them to the untested section so they
can be used with the rtl8xxxu as the rtl8192cu are well
supported.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com

wifi: rtl8xxxu: drop reference to staging drivers

The Kconfig notes mention staging drivers that have
since been removed so update the driver's description
so it no longer references the staging rtl8723au and
rtl8192u drivers which have now been deleted.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com

wifi: rtw89: wow: add net-detect support for 8852c

Enable net-detect in WoWLan stub of 8852c, and declare
net-detect support up to 8 SSIDs.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-6-pkshih@realtek.com

wifi: rtw89: wow: add delay option for net-detect

The delay option is the period in unit of second for WoWLAN firmware
to wait before the first scan. We get the option from cfg80211 and
practice it. Another, in some platform, WoWLAN firmware may found
configured network and then trigger resume process, before suspend
process is completed, lead to the wakeup function failed.
So the default value is set one to avoid the issue.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com

wifi: rtw89: wow: add WoWLAN net-detect support

Net-detect is an option of WoWLAN to allow the device to
be woken up from suspend mode when configured network is detected.

When user enables net-detect and lets the device enter suspend
state, WoWLAN firmware will periodically scan until beacon or
probe response of configured networks are received. If configured
networks are detected, WoWLAN firmware will trigger resume process.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com

wifi: rtw89: wow: implement PS mode for net-detect

When net-detect is enabled, WoWLAN firmware will periodically
scan until beacon or probe response of configured networks are
received. To reduce power consumption, the FW-IPS mode is
implemented to keep WiFi chip in idle mode between each scan.
The FW-IPS is controlled by WoWLAN firmware to turn of some critical
electrical components, and is different from the original IPS mode
which most electrical components are turned off.

Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com

wifi: rtw89: 8852c: support firmware format up to v1

Driver has supported different WoWLAN reason code by commit 0e5210217768
("wifi: rtw89: wow: update WoWLAN reason register for different FW")
since firmware version 0.27.80.0. The old driver can't support two
kinds of WoWLAN reason, so increase firmware format to v1.

Also driver tables of BB and RF registers and power values will be added
into v1 format.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com

wifi: b43: Constify struct lpphy_tx_gain_table_entry

'struct lpphy_tx_gain_table_entry' are not modified in this driver.

Constifying this structure moves some data to a read-only section, so
increase overall security.

On a x86_64, with allmodconfig:
Before:
======
   text    data     bss     dec     hex filename
  16481    6232       0   22713    58b9 drivers/net/wireless/broadcom/b43/tables_lpphy.o

After:
=====
   text    data     bss     dec     hex filename
  22305     395       0   22700    58ac drivers/net/wireless/broadcom/b43/tables_lpphy.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-By: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/e33bc9e6dff4a5b6cd8d0ab5399aa1abac5bef9d.1722753127.git.christophe.jaillet@wanadoo.fr

wifi: ath12k: fix invalid AMPDU factor calculation in ath12k_peer_assoc_h_he()

Currently ampdu_factor is wrongly calculated in ath12k_peer_assoc_h_he(), fix it.

This is found during code review.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240710021819.87216-1-quic_bqiang@quicinc.com

wifi: ath12k: match WMI BSS chan info structure with firmware definition

struct wmi_pdev_bss_chan_info_event is not similar to the firmware
struct definition, this will cause some random failures.

Fix by matching the struct wmi_pdev_bss_chan_info_event with the
firmware structure definition.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240331183232.2158756-3-quic_kathirve@quicinc.com

wifi: ath12k: fix BSS chan info request WMI command

Currently, the firmware returns incorrect pdev_id information in
WMI_PDEV_BSS_CHAN_INFO_EVENTID, leading to incorrect filling of
the pdev's survey information.

To prevent this issue, when requesting BSS channel information
through WMI_PDEV_BSS_CHAN_INFO_REQUEST_CMDID, firmware expects
pdev_id as one of the arguments in this WMI command.

Add pdev_id to the struct wmi_pdev_bss_chan_info_req_cmd and fill it
during ath12k_wmi_pdev_bss_chan_info_request(). This resolves the
issue of sending the correct pdev_id in WMI_PDEV_BSS_CHAN_INFO_EVENTID.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240331183232.2158756-2-quic_kathirve@quicinc.com

wifi: ath12k: restore ASPM for supported hardwares only

During PCI based hardware device start up, ASPM is disabled for all. And
once firmware is ready, it is restored back. However, not all hardwares
(for example QCN9274) supports ASPM. Hence there is a need to conditionally
restore ASPM back. Or else, for such hardwares, issue can be seen during
sending and receiving packets.

Introduce a new hardware param supports_aspm which identifies whether a
given hardware supports ASPM or not and then accordingly restore it.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240709055817.3371406-1-quic_adisi@quicinc.com

wifi: ath9k: Remove error checks when creating debugfs entries

We should not be checking the return values from debugfs creation at all: the
debugfs functions are designed to handle errors of previously called functions
and just transparently abort the creation of debugfs entries when debugfs is
disabled. If we check the return value and abort driver initialisation, we break
the driver if debugfs is disabled (such as when booting with debugfs=off).

Earlier versions of ath9k accidentally did the right thing by checking the
return value, but only for NULL, not for IS_ERR(). This was "fixed" by the two
commits referenced below, breaking ath9k with debugfs=off starting from the 6.6
kernel (as reported in the Bugzilla linked below).

Restore functionality by just getting rid of the return value check entirely.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219122
Fixes: 1e4134610d93 ("wifi: ath9k: use IS_ERR() with debugfs_create_dir()")
Fixes: 6edb4ba6fb5b ("wifi: ath9k: fix parameter check in ath9k_init_debug()")
Reported-by: Daniel Tobias <dan.g.tob@gmail.com>
Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240805110225.19690-1-toke@toke.dk

wifi: ath9k: use devm for gpio_request_one()

Using devm_gpio_request_one() is simpler as then we don't need to call
gpio_free().

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240731210312.7622-1-rosenp@gmail.com

wifi: ath9k: use devm for request_irq()

Avoids having to manually call free_irq(). Simplifies code slightly.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240731210243.7467-1-rosenp@gmail.com

wifi: rtw89: correct VHT TX rate on 20MHz connection

It may get wrong bitrate when connecting to AP set VHT 20MHz,
and thus we fix it to follow Wi-Fi spec.

Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com

wifi: rtw89: add support for HW encryption in unicast management frames

Add hardware encryption support for unicast management frames for
8922AE and 8852CE. Other chips will continue to use software
encryption for unicast management frames.

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com

wifi: rtw89: avoid to add interface to list twice when SER

If SER L2 occurs during the WoWLAN resume flow, the add interface flow
is triggered by ieee80211_reconfig(). However, due to
rtw89_wow_resume() return failure, it will cause the add interface flow
to be executed again, resulting in a double add list and causing a kernel
panic. Therefore, we have added a check to prevent double adding of the
list.

list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:37!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7
Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021
Workqueue: events_freezable ieee80211_restart_work [mac80211]
RIP: 0010:__list_add_valid_or_report+0x5e/0xb0
Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12
RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900
RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001
RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0
R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060
R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010
FS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0
Call Trace:
 <TASK>
 ? __die_body+0x1f/0x70
 ? die+0x3d/0x60
 ? do_trap+0xa4/0x110
 ? __list_add_valid_or_report+0x5e/0xb0
 ? do_error_trap+0x6d/0x90
 ? __list_add_valid_or_report+0x5e/0xb0
 ? handle_invalid_op+0x30/0x40
 ? __list_add_valid_or_report+0x5e/0xb0
 ? exc_invalid_op+0x3c/0x50
 ? asm_exc_invalid_op+0x16/0x20
 ? __list_add_valid_or_report+0x5e/0xb0
 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]
 drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 ? finish_wait+0x3e/0x90
 ? synchronize_rcu_expedited+0x174/0x260
 ? sync_rcu_exp_done_unlocked+0x50/0x50
 ? wake_bit_function+0x40/0x40
 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 process_scheduled_works+0x1e5/0x480
 worker_thread+0xea/0x1e0
 kthread+0xdb/0x110
 ? move_linked_works+0x90/0x90
 ? kthread_associate_blkcg+0xa0/0xa0
 ret_from_fork+0x3b/0x50
 ? kthread_associate_blkcg+0xa0/0xa0
 ret_from_fork_asm+0x11/0x20
 </TASK>
Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev
gsmi: Log Shutdown Reason 0x03
---[ end trace 0000000000000000 ]---

Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-4-pkshih@realtek.com

wifi: rtw89: 8922a: Add new fields for scan offload H2C command

Update scan offload H2C format to fit firmware version 35.21.
The new fields indicate lengths of variable length members, so
when driver and firmware are using mismatch version, FW could
handle the parsing better.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com

wifi: rtw89: 8922a: new implementation for RFK pre-notify H2C

For firmware version 0.35.31 and above, update H2C RFK
pre-notify to new implementation. Rename existing H2C
to v0 for backward compatibility.

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com

wifi: brcmsmac: clean up unnecessary current_ampdu_cnt and related checks

In 'brcms_c_ffpld_check_txfunfl()', 'current_ampdu_cnt' is hardcoded to
zero, so 'txunfl_ratio' is always zero as well and some dead code can be
removed. Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240801101531.6626-1-d.kandybka@gmail.com

wifi: brcmfmac: introducing fwil query functions

When the firmware interface layer was refactored it provided various
"get" and "set" functions. For the "get" in some cases a parameter
needed to be passed down to firmware as a key indicating what to
"get" turning the output parameter of the "get" function into an
input parameter as well. To accommodate this the "get" function blindly
copies the parameter which in some places resulted in an uninitialized
warnings from the compiler. These have been fixed by initializing the
input parameter in the past. Recently another batch of similar fixes
were submitted to address clang static checker warnings [1].

Proposing another solution by introducing a "query" variant which is used
when the (input) parameter is needed by firmware. The "get" variant will
only fill the (output) parameter with the result received from firmware
taking care of proper endianess conversion.

[1] https://lore.kernel.org/all/20240702122450.2213833-1-suhui@nfschina.com/

Fixes: 81f5dcb80830 ("brcmfmac: refactor firmware interface layer.")
Reported-by: Su Hui <suhui@nfschina.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240727185617.253210-1-arend.vanspriel@broadcom.com

wifi: brcmfmac: fwsignal: Use struct_size() to simplify brcmf_fws_rxreorder()

In the "struct brcmf_ampdu_rx_reorder", change the 'pktslots' field into
flexible array.

It saves the size of a pointer when the memory is allocated and avoids
an indirection when the array is used.
It also removes the usage of a pointer arithmetic and saves a few lines of
code.

Finally, struct_size() can be used. It is not a must have here, because
it is easy to see that buf_size can not overflow, but still, it is a good
practice.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/f4ca6b887ca1290c71e76247218adea4d1c42442.1721547559.git.christophe.jaillet@wanadoo.fr

wifi: mwifiex: add host mlme for AP mode

Add host based MLME to enable WPA3 functionalities in AP mode.
This feature required a firmware with the corresponding V2 Key API
support. The feature (WPA3) is currently enabled and verified only
on IW416. Also, verified no regression with change when host MLME
is disabled.

Signed-off-by: David Lin <yu-hao.lin@nxp.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240704033001.603419-3-yu-hao.lin@nxp.com

wifi: mwifiex: add host mlme for client mode

Add host based MLME to enable WPA3 functionalities in client mode.
This feature required a firmware with the corresponding V2 Key API
support. The feature (WPA3) is currently enabled and verified only
on IW416. Also, verified no regression with change when host MLME
is disabled.

Signed-off-by: David Lin <yu-hao.lin@nxp.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240704033001.603419-2-yu-hao.lin@nxp.com

wifi: mwifiex: increase max_num_akm_suites

The maximum number of AKM suites will be set to two if not specified by
the driver. Set it to CFG80211_MAX_NUM_AKM_SUITES to let userspace
specify up to ten AKM suites in the akm_suites array.

Without only the first two AKM suites will be used, further ones are
ignored.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240530130156.1651174-1-s.hauer@pengutronix.de

wifi: rtw89: pass chanctx_idx to rtw89_btc_{path_}phymap()

Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan
with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip
supports multiple channels.

So, change their prototype and pass chanctx_idx ahead. Let callers still
pass RTW89_CHANCTX_0 for now, but we will refine callers in the following.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com

wifi: rtw89: fw: correct chan access in assoc_cmac_tbl_g7 and update_beacon_be

Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0.
They are problematic when the chip supports multiple channels. So, correct
them by accessing right chan under rtwvif.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com

wifi: rtw89: pass rtwvif to RFK scan

For chips supporting multiple channels, they need to get target info
from rtwvif, e.g. PHY index and Chanctx index.

So, change rfk_scan prototype and pass rtwvif ahead.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com

wifi: rtw89: pass rtwvif to RFK channel

For chips supporting multiple channels, they need to get target info
from rtwvif, e.g. PHY index and Chanctx index.

So, change rfk_channel prototype and pass rtwvif ahead.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com

wifi: rtw89: rename sub_entity to chanctx

Originally, we planed to fill MAC_0/1 indicators with chanctx and
use sub_entity_xxx for these things. However, there are some reasons
listed below which make us give up this plan after we know our Wi-Fi 7
HW design.
1. one link is bound to one HW band during its life time
   but, one link might change chanctx dynamically
2. in concurrent mode, assume 1st vif is MLD
   1st vif's 2nd link might use the same chanctx as 2nd vif
   but, they are not on the same HW band
So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be
more readable, we rename sub_entity related words to chanctx.

No logic is changed.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com

wifi: rtw89: mcc: stop at a role holding chanctx

In general, MCC (multi-channel concurrency) stops when some chanctx is
unassigned. Originally, we let FW to stop at a fixed role. However, it
might be the one to be unassigned.

So, iterate MCC roles and select one which is still holding chanctx.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-3-pkshih@realtek.com

wifi: rtw89: chan: refine MCC re-plan flow when unassign chanctx

Originally during unassign-chanctx, MCC (multi-channel concurrency) is
re-planed before set-channel if need. But, we might calculate MCC stuffs
based on old channel info. And, the following set-channel might be racing
with FW MCC state mechanism. So, we refine this flow. Now, if MCC re-plan
is needed here, it will be done after set-channel.

Besides, to be more rigorous, we now ensure entity isn't paused before we
deal with MCC things here.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240727080650.12195-2-pkshih@realtek.com

wifi: rtw88: always wait for both firmware loading attempts

In 'rtw_wait_firmware_completion()', always wait for both (regular and
wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'
has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue
'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually
the wowlan one) is still in progress, causing UAF detected by KASAN.

Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported")
Reported-by: syzbot+6c6c08700f9480c41fe3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240726114657.25396-1-dmantipov@yandex.ru

wifi: rtw89: fix typo of rtw89_phy_ra_updata_XXX

`updata` should be `update`

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com

wifi: rtw89: 885xb: reset IDMEM mode to prevent download firmware failure

For different firmware type, it could change IDMEM mode, so reset it to
default to avoid encountering error for RTL8851B/RTL8852B/RTL8852BT
if that kind of firmware was downloaded before.

    rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 5
    rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 3
    rtw89_8851be 0000:02:00.0: MAC has already powered on
    rtw89_8851be 0000:02:00.0: fw security fail
    rtw89_8851be 0000:02:00.0: download firmware fail
    rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x1E0 = 0x62
    rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x83F2 = 0x8
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f500
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c
    rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524
    rtw89_8851be 0000:02:00.0: failed to setup chip information
    rtw89_8851be: probe of 0000:02:00.0 failed with error -16

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724052626.12774-4-pkshih@realtek.com

wifi: rtw89: add support for hardware rfkill

Add support for ieee80211::rfkill_poll ops. This enables periodic
monitoring of the hardware rfkill state, triggering updates when the
status changes.

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com

wifi: rtw89: add EVM statistics for 1SS rate

To more accurately debug performance issues, EVM statistics will
differentiate between different space streams, and only beacon
and data frames will be included.

Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724052626.12774-2-pkshih@realtek.com

wifi: rtw88: 8822c: Parse channel from IE to correct invalid hardware reports

For CCK packets we could get incorrect reports from hardware.
And this causes wrong frequencies being reported. Parse the channel
information from IE if provided by AP to fix this.

Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240724050501.7550-1-pkshih@realtek.com

wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()

In 'ath9k_get_et_stats()', promote TX stats counters to 'u64'
to avoid possible integer overflow. Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240725111743.14422-1-d.kandybka@gmail.com

wifi: ath9k: Use swap() to improve ath9k_hw_get_nf_hist_mid()

Use the swap() macro to simplify the ath9k_hw_get_nf_hist_mid() function
and improve its readability.

Fixes the following Coccinelle/coccicheck warning reported by
swap.cocci:

  WARNING opportunity for swap()

Compile-tested only.

Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240710185743.709742-2-thorsten.blum@toblux.com

wifi: ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader

Only managed PCI resource in the driver is the iomapped bar. However the bar
is unmapped in the same function. Therefore using the device-managed
versions just causes overhead, w/o any benefit. Once this is switched to the
non-managed versions, there's nothing left to be managed for
pcim_enable_device(). Therefore we can reduce overhead here too and switch to
the non-managed version as well. This includes removing the no longer needed
call to pcim_pin_device().

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/3b46f6c7-4372-4cc9-9a7c-2c1c06d29324@gmail.com

wifi: rtw88: 8703b: Fix reported RX band width

The definition of GET_RX_DESC_BW is incorrect. Fix it according to the
GET_RX_STATUS_DESC_BW_8703B macro from the official driver.

Tested only with RTL8812AU, which uses the same bits.

Cc: stable@vger.kernel.org
Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Tested-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1cfed9d5-4304-4b96-84c5-c347f59fedb9@gmail.com

wifi: rtw88: 8822c: Fix reported RX band width

"iw dev wlp2s0 station dump" shows incorrect rx bitrate:

tx bitrate:     866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
rx bitrate:     86.7 MBit/s VHT-MCS 9 VHT-NSS 1

This is because the RX band width is calculated incorrectly. Fix the
calculation according to the phydm_rxsc_2_bw() function from the
official drivers.

After:

tx bitrate:     866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
rx bitrate:     390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1

It also works correctly with the AP configured for 20 MHz and 40 MHz.

Tested with RTL8822CE.

Cc: stable@vger.kernel.org
Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/bca8949b-e2bd-4515-98fd-70d3049a0097@gmail.com

wifi: rtw89: 8852bt: add 8852BE-VT to Makefile and Kconfig

RTL8852BE-VT is a WiFi 6 2x2 chip, which can operate on 2/5 GHz channels
and 80MHz bandwidth.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-8-pkshih@realtek.com

wifi: rtw89: 8852bte: add PCI entry of 8852BE-VT

PCI device ID 10ec:b520 of RTL8852BE-VT is added as PCI entry, and define
chip capabilities for driver common routines.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-7-pkshih@realtek.com

wifi: rtw89: 8852bt: declare firmware features of RTL8852BT

Firmware features are enabled after being supported, including TX wake,
firmware crash simulation, hardware scan.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-6-pkshih@realtek.com

wifi: rtw89: 8852bt: add chip_ops of RTL8852BT

Add chip_info of RTL8852BT accordingly, including power on/off function,
BB reset, TSSI settings while setting channel, RF calibration, and
BT coexistence.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-5-pkshih@realtek.com

wifi: rtw89: 8852bt: add chip_info of RTL8852BT

Add chip_info of RTL8852BT accordingly, including firmware elements
support, MAC memory quota (WDE, PLE and etc), SER IMR used by firmware,
BTC registers, register based H2C/C2H, WoWLAN stub.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-4-pkshih@realtek.com

wifi: rtw89: 8852bt: rfk: use predefined string choice for DPK enable/disable

clang warns precedence of '?:' and '&'. Even though original logic is
correct, use str_enable_disable() to avoid clang confusing. Another way to
fix is to add parentheses around '&', but I choose former one.

  >> drivers/net/wireless/realtek/rtw89/rtw8852bt_rfk.c:1827:46: warning:
     operator '?:' has lower precedence than '&'; '&' will be evaluated
     first [-Wbitwise-conditional-parentheses]
    1827 |                     kidx, dpk->is_dpk_enable & off_reverse ? "enable" : "disable");
         |                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202407200741.dMG9uvHU-lkp@intel.com/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-3-pkshih@realtek.com

wifi: rtw89: 8852bt: add set_channel_rf

Add RF part of set_channel() is to configure RF registers, and then
hardware can TX/RX on specified frequency and bandwidth.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240720021340.12102-2-pkshih@realtek.com