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.

Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240115-wilc_1000_fixes-v1-1-54d29463a738@bootlin.com

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.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240110115314.421298-1-dmantipov@yandex.ru

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>

wifi: cfg80211: fix kernel-doc for cfg80211_chandef_primary

This was still referring to cfg80211_chandef_primary_freq(),
fix it.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: b82730bf57b5 ("wifi: cfg80211/mac80211: move puncturing into chandef")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.581427dc81fc.I9a109d02b4349807dce521c693ecd3516ec58cc0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.825245e0803f.Ic607c57f43eb7c7ff122ffee8f3994fd040d578f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: show skb_mac_gso_segment() failure reason

If this warning triggers we don't really know why, print out
the return value so we can see it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.b1b907741e85.Ib8ee9c90bd8f1af69969981ff0c63e9cc3123e1f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: remove flags for enable/disable beacon filter

The flags argument to enable/disable beacon filtering functions
is unused and always zero, so just remove it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.2c739c1034a5.I8619949ad4ebd31593d10ece371ebdc6c48db98f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Fixes: 79e561f0f05a ("iwlwifi: mvm: d3: implement RSC command version 5")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.462101146fef.I10f3855b99417af4247cff04af78dcbc6cb75c9c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: pcie: Add new PCI device id and CNVI

Add the support for a new PCIE device-id 0x272E and a new CNVI
type.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.506db9b4a664.Ia2e3a77b880c449ac0e8d20b8cea25e6f07f1b81@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: don't send the smart fifo command if not needed

Newer firmware versions no longer needs this command. Don't send it if
the firmware advertises it does not need it.

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

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.

Fixes: 5c75a208c244 ("wifi: iwlwifi: mvm: support new key API")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.2f2c602ab3c6.If13b2e2fa532381d985c07df130bee1478046c89@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.9b4c06b5d533.Idf699b36ec95ee36f530355cd2cb1da297a098f1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.4fea3bd2d4a6.Ib80764f4581d875cff08469016894f7c817c3828@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Fixes: 7b3e42ea2ead ("iwlwifi: support multiple tfd queue max sizes for different devices")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.4148a6ef54e0.I733a70f679c25f9f99097a8dcb3a1f8165da6997@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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).

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.2be5b35be30f.I99db8700d01092d22a6d76f1fc1bd5916c9df784@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: always update keys in D3 exit

If during D3 there was both a GTK rekey and a
disconnection, when waking up, we must first
update the new keys and then disconnect.

The reason is that when disconnecting we first need
to remove the keys.
Trying to remove invalid keys results in firmware
assert.

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.68cf3974b5d7.Iac9b71a1906ab973aba9baadc9e923b63c0b4945@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.ca55b3a7fa8d.Id746846f187442ebc689416d2688f2bd9278c0e9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: combine condition/warning

WARN() returns the value of the condition, so it's
nicer to combine the warning and the if.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.44f63334760e.If0a2cf347a8676a3830c5c3183a257fe11f31419@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.bdd0511c007d.I3325288c64c010a4d008ac4429de1c2b14ef764c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Daniel Amosi <amosi.daniel@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.080195242c18.Ib166fc4e46666165a88e673a4a196cb8f18fdec4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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

Fixes: 135065837310 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION cmd")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240205211151.c61820f14ca6.Ibbe0f848f3e71f64313d21642650b6e4bfbe4b39@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.dcaa3325773f.I649079c842369dcae3a362842322deca422a61d5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.4e0745e2cd97.I311dc623ce68de6a2da3c21c8d84a387844f714a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: define RX queue sync timeout as a macro

define the timeout on RX queues notification as a macro so it will be
clearer.

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.a6985ea87751.Iafb7ae13aa58d66512e4b3fa6c75149c75cbc305@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: expand queue sync warning messages

It's a bit tricky to understand what's going on here, add
more data to the warning messages to make that clearer.

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

wifi: iwlwifi: mvm: Declare support for secure LTF measurement

Declare support for secure LTF measurement if the FW supports it.

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

wifi: iwlwifi: mvm: advertise support for protected ranging negotiation

Advertise support for protected ranging negotiation if the firmware
supports it.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206135637.9bb7e13ad18c.I578af1c9836e91069ce318b265bd221f42955992@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.0a09ab337b54.I0dfe239dc30577a2ff23f910b10e9957364ccc78@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: support EHT for WH

sku_cap_11be_enable should be set to true also for WH.

Fixes: e1374ed25324 ("wifi: iwlwifi: Add support for new CNVi (SC)")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://msgid.link/20240204235836.a6d4097cbaca.I8b00fa7b6226b4116cd91f70fb0b15e79b4dee5a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: don't support reduced tx power on ack for new devices

This is no longer supported by the firmware.

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

wifi: iwlwifi: use system_unbound_wq for debug dump

This can take some time, so it's better to use the unbound
workqueue.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.75c8d2286f81.I478e9faf422f22ae66c0a113003fea83565c5692@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: remove EHT code from mac80211.c

The code here is the pre-MLD API, but of course older FW
that doesn't support MLD APIs cannot support EHT. Remove
some code that shouldn't be there.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.bde5a9d87759.I4c69dd94416f92b0f1f53dd57dafecbec643600d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: read mac step from aux register

in BZ, the mac step is not updated to the HW REV CSR.
For BZ-I, read it from the CNVI aux register
For BZ-U always take B step.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.dcc18b533f13.I0a6267fa0a142744bcf7500b45f667b596b492c5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240204235836.a68ee2b6cb58.Iddc47c608ec990b12be0ae5b1ee89bcf6beb0f6a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: const-ify chandef pointers

In much of the PHY context handling code the chandef
coming from mac80211 is read-only, mark them const
to make that clearer.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.e7fbd3e26d85.I72d72e61dc5f5fc76c53e32cb60b66237eaedec3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.d17425824b11.If2c1b29e3c579f4135383681af2d625cfe2cffcd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240204235836.794c5387e67e.I064365428815ec3135afa345fbbde78449b60203@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: add HONOR to PPAG approved list

Add HONOR to the list of the OEMs that are allowed to use
the PPAG feature

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

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.

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-6-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: start and finalize channel switch on link basis

Add changes to start a channel switch as well as finalize it on link basis
in order to support CSA with MLO as well.

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-5-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-4-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-3-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240130140918.1172387-2-quic_adisi@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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>

wifi: cfg80211: Add utility for converting op_class into chandef

This utility is used in STA CSA handling. The op_class in the ECSA
Element can be converted into chandef.

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-2-michael-cy.lee@mediatek.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: return negative -EINVAL instead of positive EINVAL

The '-' character is missing in -EINVAL.

Fixes: fc7214c3c986 ("wifi: iwlwifi: read DSM functions from UEFI")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://msgid.link/f0391316-ab30-4664-96ac-03445ab2aeba@moroto.mountain
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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>

wifi: mac80211_hwsim: add missing kernel-doc

Some kernel-doc is missing here, add it.

Link: https://msgid.link/20240206134555.eb95c1dfc1f0.Ibaf8b3249d9de59358bf6503fe4a186d9ac6544d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: add missing kernel-doc for fast_tx_check

This was added earlier, add kernel-doc for it.

Link: https://msgid.link/20240206134555.6354b0ac8610.Ib90d3651834c556b73697388f59bd396a1f6f9b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240131164910.60066625a239.Idfb6a5a9876f9f631eae760055e1c4018259a971@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129203544.ef7258d5790d.Idafe22e41621757458d4960659b9621853f7104d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: convert ieee80211_ie_build_eht_cap() to SKB use

Convert ieee80211_ie_build_eht_cap() to the SKB-put function
style, renaming it to ieee80211_put_eht_cap().

Link: https://msgid.link/20240129202041.ece9769e3c94.Ibd17bea6311f0c7ba56f6c1803fa3208abaaebb9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: convert ieee80211_ie_build_he_cap() to SKB use

Convert ieee80211_ie_build_he_cap() to the SKB-put function
style, renaming it to ieee80211_put_he_cap().

Link: https://msgid.link/20240129202041.e6ef888980d9.Ied9e014314b5d27611e693e3d4cb63bdc8d7de17@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: move element parsing to a new file

This code got really big, move it to a new file.
Pure code move.

Link: https://msgid.link/20240129202041.7f27f7c895e4.I0adfc28bd656a4d44c2bf47966277eecf56cbaa0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129202041.c3a8e3c2cc99.I9d9920858c30ae5154719783933de0d7bc2a2cb9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: simplify adding supported rates

Make this a new-style "put" function, and change the
parameters to pass more information directly, this
makes it usable also for the MLME code.

Link: https://msgid.link/20240129202041.f604a03bd728.I8c798ea45b8479ac9982e77d0378af11a09ccdaf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129202041.6454ac78ff8c.I7152e3c27645105478c68d40ca493feb27cac6bf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: rename ieee80211_ie_build_he_6ghz_cap()

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.

Link: https://msgid.link/20240129202041.b8064a4e73b5.I8d2f4526562029107c6414c6cda378b300b1b0b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: limit HE RU capabilities when limiting bandwidth

When limiting a station's supported bandwidth while connecting,
also limit various other HE capabilities according to the bandwidth
needed for them.

Link: https://msgid.link/20240129202041.34be99efca25.I02a695961bc6aadd37768b17c50fcdec4427d460@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129202041.b5f6df108c77.I0d8ea04079c61cb3744cc88625eeaf0d4776dc2b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: simplify HE/EHT element length functions

We don't need to pass the iftype there, we already have it
in the sdata. Simplify this code.

Link: https://msgid.link/20240129202041.5890eb1d4184.Ibce7e5abcc7887630da03ac2263d8004ec541418@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129200652.23f1e3b337f1.Idd2e43cdbfe3ba15b3e9b8aeb54c8115587177a0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129200652.1a69f2a31ec7.I55b86561d64e7ef1504c73f6f2813c33030c8136@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: implement MLO multicast deduplication

If the vif is an MLD then it may receive multicast from
different links, and should drop those frames according
to the SN. Implement that.

Link: https://msgid.link/20240129200456.693b77d14b44.I491846f2bea0058c14eab6422962c10bfae9b675@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: add/use ieee80211_get_sn()

This will also be useful for MLO duplicate multicast
detection, but add it already here and use it in one
place that trivially converts.

Link: https://msgid.link/20240129200456.f0ff49c80006.I850d2785ab1640e56e262d3ad7343b87f6962552@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://lore.kernel.org/linux-wireless/20220214223051.3610-1-quic_alokad@quicinc.com/
Suggested-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://msgid.link/20240129194108.307183a5d2e5.I4d7fe2f126b2366c1312010e2900dfb2abffa0f6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: use cfg80211_chandef_primary_freq()

Instead of calculating the new primary 40/80/160 MHz
center frequency here, use the new helper function from
cfg80211.

Link: https://msgid.link/20240129194108.eb59d6433d18.I74b745f0d1a32e779fb25d50c56407be7c35b840@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: cfg80211: simplify cfg80211_chandef_compatible()

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.

Link: https://msgid.link/20240129194108.be3e6eccaba3.I8399c2ff1435d7378e5837794cb5aa6dd2ee1416@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: wireless: declare different S1G chandefs incompatible

It doesn't look like we can get into this code, but make it
more robust and declare two S1G chandefs to be incompatible
unless they're identical.

Link: https://msgid.link/20240129194108.b28fb0644a8c.I9297ada5cf1baf00dbbdf8fcffd1806883489fc9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: refactor puncturing bitmap extraction

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.

Link: https://msgid.link/20240129194108.d9f50dcec8d0.I8b08cbc2490a734fafcce0fa0fc328211ba6f10b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.1ca184427c76.I077deb8d52c4648eac145b63f88b6c5a3b920ddc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: validate assoc response channel config

Due to the earlier restructuring we now mostly ignore
the channel configuration in the association response,
apart from the HT/VHT checks we had.

Don't do that, but parse it and update, also dropping the
association if the AP changed its mode in the response.

Link: https://msgid.link/20240129194108.b3efa5eae60c.I1b70c9fd56781b22cdfdca55d34d69f7d0733e31@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.d3d5b35dd783.I939d04674f4ff06f39934b1591c8d36a30ce74c2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.7240829bd96d.I5ccbb8dd019cbcb5326c85d76121359225d6541a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: chan: chandef is non-NULL for reserved

The last caller of this with a NULL argument was related to
the non-chanctx code, so we can now remove this odd logic.

Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.bad8ec1e76c8.I12287452f42c54baf75821e75491cf6d021af20a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.d06f85082e29.I47e68ed3d97b0a2f4ee61e5d8abfcefc8a5b9c08@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129194108.9451722c0110.I3e61f4cfe9da89008e1854160093c76a1e69dc2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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.

Link: https://msgid.link/20240129194108.70a97bd69265.Icdd8b0ac60a382244466510090eb0f5868151f39@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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>

wifi: mac80211: remove unused MAX_MSG_LEN define

This got unused when the tracing was converted to dynamic
strings, so the define can be removed.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

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>

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.

Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240205093040.1941140-1-martin.kaistra@linutronix.de

bcma: make bcma_bus_type const

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

ssb: make ssb_bustype const

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

wifi: wfx: fix memory leak when starting AP

Kmemleak reported this error:

    unreferenced object 0xd73d1180 (size 184):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00  ................
      backtrace:
        [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
        [<127bdd74>] __alloc_skb+0x144/0x170
        [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
        [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
        [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [<47bd8b68>] genl_rcv_msg+0x198/0x378
        [<453ef796>] netlink_rcv_skb+0xd0/0x130
        [<6b7c977a>] genl_rcv+0x34/0x44
        [<66b2d04d>] netlink_unicast+0x1b4/0x258
        [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
        [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
        [<d2b5212d>] ___sys_sendmsg+0x80/0xb4
        [<69954f45>] __sys_sendmsg+0x64/0xa8
    unreferenced object 0xce087000 (size 1024):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [<9a993714>] __kmalloc_track_caller+0x230/0x600
        [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
        [<a2c61343>] __alloc_skb+0xa0/0x170
        [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
        [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
        [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [<47bd8b68>] genl_rcv_msg+0x198/0x378
        [<453ef796>] netlink_rcv_skb+0xd0/0x130
        [<6b7c977a>] genl_rcv+0x34/0x44
        [<66b2d04d>] netlink_unicast+0x1b4/0x258
        [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
        [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
        [<d2b5212d>] ___sys_sendmsg+0x80/0xb4

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

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 ]  |
           |  ...                      |
           +---------------------------+

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240204012627.9647-5-pkshih@realtek.com

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.

  +---------------------------+
  |      firmware header      |
  |                           |
  | +-----------------------+ |
  | | section type/size * N-|-|-------+
  | | ...                   | |       |
  | +-----------------------+ |       |
  +---------------------------+       |
  :                           :       |
  +---------------------------+ -\    |
  | secure section type (ID:9)|  |    |
  |                           |  | <--+
  |                           |  |
  +---------------------------+ -/
  |MSS Pool for above section |
  |                           |
  |                           |
  +---------------------------+

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240204012627.9647-4-pkshih@realtek.com

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.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240204012627.9647-3-pkshih@realtek.com

wifi: rtw89: fw: consider checksum length of security data

The newer firmware file provides security data with checksum, so we need to
consider the length. Otherwise it will fail to validate total firmware
length resulting in failed to probe.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240204012627.9647-2-pkshih@realtek.com

wifi: rtw89: 8922a: add chip_ops::rfk_hw_init

Add a chip_ops for WiFi 7 chips to set additional RF configurations
including MLO and PLL settings.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-12-pkshih@realtek.com

wifi: rtw89: 8922a: add chip_ops::rfk_init_late to do initial RF calibrations later

The RF calibrations are moved into firmware, so we trigger calibrations by
H2C commands and wait for C2H completion events. However, these events
can be received only after HCI (i.e. PCI for now) starts, so we should
do initial RF calibrations after that.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-11-pkshih@realtek.com

wifi: rtw89: 8922a: rfk: implement chip_ops to call RF calibrations

Calling RF calibrations when interface up, connection, switching bands and
going to scan.

For 8922AE, RF calibrations are moved to firmware, so use H2C commands to
trigger RF calibrations and wait for a C2H event to indicate completion.
Then, do next RF calibration.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-10-pkshih@realtek.com

wifi: rtw89: rfk: add H2C command to trigger TSSI

TSSI is short for transmitter signal strength indication, which is a
close-loop hardware circuit to feedback actual transmitting power as a
reference to adjust power for next transmission.

When connecting and switching bands or channels, do TSSI calibration and
reset hardware status to output expected power.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-9-pkshih@realtek.com

wifi: rtw89: rfk: add H2C command to trigger TXGAPK

TXGAPK stands for TX power gap calibration. Use this calibration to
compensate TX power gap to output expected power.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-8-pkshih@realtek.com

wifi: rtw89: rfk: add H2C command to trigger DACK

DACK (digital-to-analog converters calibration) is used to calibrate DAC
to output signals with expected quality.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-7-pkshih@realtek.com

wifi: rtw89: rfk: add H2C command to trigger DPK

DPK is short for digital pre-distortion calibration. It can adjusts digital
waveform according to PA linear characteristics dynamically to enhance
TX EVM.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-6-pkshih@realtek.com

wifi: rtw89: rfk: add H2C command to trigger RX DCK

RX DCK is receiver DC calibration. This will calibrate DC offset to
reflect correct received signal strength indicator, so mechanisms like CCA
can have normalized values.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240202030642.108385-5-pkshih@realtek.com