wifi: iwlwifi: fw: support reading PPAG BIOS table revision 4

PPAG revision 4 data has more supported bits than supported in
version 6 of PPAG command. So, adjust by masking accordingly to
firmware acceptance.

Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.f1cb31f9f6ab.I56d6887866f76fd02b2cd298e3de1189c6d3890e@changeid

wifi: iwlwifi: rename ppag_ver to ppag_bios_rev

ppag_ver variable is holding PPAG BIOS revision but name misleading
as PPAG command API version, So rename to ppag_bios_rev.

This will improve code readability but doesn't alter behaviour.

Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.be51850947df.If81d88cd2d38299faf1e2a3db5efbc021650f907@changeid

wifi: iwlwifi: mld: don't return an error if the FW is dead

If iwl_mld_change_vif_links failed to add the requested link(s)
because the FW is dead (error before recovery), there is no point
in returning an error value, as the reconfig will re-add the link(s)
after the FW is started.
Return 0 in that case, and WARN in the others.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250430151952.c549c72b1f37.I445bf723e9befc9541b4abd0ec7c72db8f1ff177@changeid

wifi: iwlwifi: mld: check for NULL before referencing a pointer

Errors can happen, and it is better not to risk with a NULL pointer
dereference.
Make sure that the links-to-remove pointers are not NULL before
dereferencing it.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250430151952.408652d45cda.I1bb72836dab17895a2e39910e4493d667db0fa80@changeid

wifi: iwlwifi: mld: allow EMLSR with 2.4 GHz when BT is ON

When BT is ON, EMLSR with one of the links operating on 2.4 GHz
is allowed only if it meets following conditions.
In this patch:
1. during link selection, when BT is ON, allow emlsr only if BT
   pentalty is < 7%.
2. exit EMLSR if BT is turned ON and one of the links is operating
   on 2.4 GHz with BT penalty > 7%

Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.d30212ec3901.I48e3d5bd6b0b8583f98057c38d2ee30fff5abd8a@changeid

wifi: iwlwifi: implement TOP reset follower

For the upcoming SC hardware, a new reset mode "(silent) TOP
reset" will be available. When BT initiates that reset, it'll
negotiate with the WiFi firmware which makes it appear to the
driver as the reset interrupt. To distinguish it from all the
other reasons for the reset interrupt, there's (now) a status
field in CSR 0x110.

Implement the part of TOP reset where we react to BT doing it.
This requires disambiguating the interrupt, depending on the
state of the device, since we can even get TOP reset from BT
while waiting for the reset handshake.

If TOP reset is done by BT while we're not trying to do reset
anyway, then simply reprobe, since we cannot keep the state
of the device as it's being reset, after waiting the needed
180ms to let the device reset/settle.

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

wifi: iwlwifi: avoid scheduling restart during restart

When a restart is in progress, it can be async due to the next
worker being scheduled in mac80211 (restart work) or the driver
itself (reprobe). Avoid scheduling another restart during this
period.

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

wifi: iwlwifi: mld: tests: extend link pair tests

Generalize and extend the link pair tests to not just do
channel load checks, but generally check link pairs. To
enable more accurate checking, return the reasons bitmap
from iwl_mld_valid_emlsr_pair() and therefore rename it
to iwl_mld_emlsr_pair_state.

It's also necessary now to add more chandefs, and while
doing so fix the existing ones to be valid and add a
test to check they really are valid.

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

wifi: iwlwifi: mld: refactor tests to use chandefs

Instead of building invalid chandefs on the fly, use only
chandefs throughout and ensure those are valid. Also add
more chandefs that will be needed for new tests.

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

wifi: iwlwifi: mld: send the WPFC table to the FW

Read the table on op mode start, and send it to the FW when it is
loaded.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.e349a33cd871.Ied196cf0fbe18b82b87ce713c4e3347f9aca1c25@changeid

wifi: iwlwifi: read WPFC also from UEFI

We are currently reading it only from ACPI, but we need to read it from
UEFI too (if exists, and if the UEFI variables are locked)

Add the reading from the UEFI and use IWL_BIOS_TABLE_LOADER to generate
the code that determines the source from which the table should be read
(ACPI/UEFI).

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.839a5e7dd89b.I491acbf68047874df97b3971f1ba692ebc998a52@changeid

wifi: iwlwifi: prepare for reading WPFC from UEFI

IWL_BIOS_TABLE_LOADER generates the code that determines from what source
to read a BIOS table (ACPI or UEFI).
As we want to read WPFC from UEFI to, iwl_acpi_get_phy_filters needs to
have the prototype that is required by this macro:
receive fwrt and return a int on success/failure.
Do that.

This allowes us to make to version of iwl_acpi_get_phy_filters for non
ACPI builds back to an iniline function.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20250430151952.8046a2db775b.Ifbcf4168183d3cd635e3e800ec7ecd903e57d361@changeid

wifi: iwlwifi: Add short description to enum iwl_power_scheme

The kernel-doc script flagged the following:

drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:130: warning: missing initial short description on line:
 * enum iwl_power_scheme
1 warnings as Errors

Add a short description to address this warning.

Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250319-iwl_power_scheme-kdoc-v1-1-2033ae38b178@oss.qualcomm.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>

Revert "wifi: iwlwifi: clean up config macro"

This reverts commit b6abf63ed7719f6dc1f7e36375b970126e29e709.

This is causing major merge conflicts with the changes in
wireless, where we reverted some changes. Revert this for
now to avoid having to solve that problem. We can redo it
on top of wireless-next with wireless merged back later.

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

wifi: iwlwifi: move phy_filters to fw_runtime

phy_filters holds the values as read from WFPC BIOS table.
Since also iwlmld is going to need it, move it to fw_runtime.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250424153620.357baa65950a.I01d22328b4c381d4c0064ad9bd36750911157f90@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: pcie: make sure to lock rxq->read

rxq->read is accessed without the rxq->lock in a few places,
Make sure to have the lock there.

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

wifi: iwlwifi: add definitions for iwl_mac_power_cmd version 2

This version has a new flag bit that indicates whether or not SMPS is
allowed for the MAC.
This only adds the API, the actual support will be done in other
patches.

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

wifi: iwlwifi: clean up config macro

The IWL_DEV_INFO() macro has far too many arguments, and most
of the time they're just "ANY". Use C99 initializers in the
macro to clean that up.

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

wifi: iwlwifi: mld: simplify iwl_mld_rx_fill_status()

Move some code that's only done when having received data out
of iwl_mld_rx_fill_status() and remove the two arguments that
are related to that. This simplifies the function for the no-
data case.

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

wifi: iwlwifi: mld: rx: simplify channel handling

There's no need to have the channel in phy_data, this
code only supports one descriptor format so can use
it directly from there.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250424153620.409c2f4ecbcc.I1735cd773ed07ad9fae44bdfc46261fa9a8fd0e0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: clean up band in RX metadata

Use u8_get_bits() instead of open-coding, and adjust the
name as well. Also don't use enum nl80211_band for the
variable holding an entirely different type.

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

wifi: iwlwifi: mld: skip unknown FW channel load values

The firmware statistics were previously reporting bogus/old
channel load values if the device hadn't been active on a
given channel; it'll report an unknown value now for those
statistics affected (channel_load and channel_load_not_by_us.)
Handle that by simply skipping the value, the averaging would
result in the exact same value as before.

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

wifi: iwlwifi: define API for external FSEQ images

The firmware will support external FSEQ images, define the
necessary API for that. We're not yet using/shipping such,
so don't add code to load them for now.

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

wifi: iwlwifi: mld: allow EMLSR on separated 5 GHz subbands

If there are two links on 5 GHz subbands that are separated
enough (using channels 36-64 and 100+) then we can support
EMLSR across those two links. Allow that in the logic.

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

wifi: iwlwifi: mld: use cfg80211_chandef_get_width()

We can use this helper now to simplify some code.

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

wifi: iwlwifi: mld: fix iwl_mld_emlsr_disallowed_with_link() return

The return type of iwl_mld_emlsr_disallowed_with_link() is a u32
bitmap of exit reasons, but in the data structure confusion case
where the warning triggers, it returns false. Add a new reason
bit for this case so it doesn't return that EMLSR is possible.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250424153620.d1f8465e2b5e.I58c463c70801231a79b04c1ff600f41afcbb04f5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mld: clarify variable type

In iwl_mld_emlsr_disallowed_with_link() the code uses an
enum for a bitmap of values from it, which doesn't really
make sense.Use u32 for the variable just like the return
value.

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

wifi: iwlwifi: pcie: add support for the reset handshake in MSI

Add the proper case in the MSI interrupt handler and read the non-MSIx
interrupt cause register in case of timeout.

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

wifi: mac80211_hwsim: Prevent tsf from setting if beacon is disabled

Setting tsf is meaningless if beacon is disabled, so check that beacon
is enabled before setting tsf.

Reported-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=064815c6cd721082a52a
Tested-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Link: https://patch.msgid.link/tencent_3609AC2EFAAED68CA5A7E3C6D212D1C67806@qq.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Merge tag 'ath-next-20250418' of git://git./linux/kernel/git/ath/ath into wireless-next

Jeff Johnson says:
====================
ath.git patches for v6.16

ath12k:
Enable AHB support for IPQ5332.
Add monitor interface support to QCN9274.
Add MLO support to WCN7850.
Add 802.11d scan offload support to WCN7850.

ath11k:
Restore hibernation support

In addition, perform the usual set of bug fixes and cleanups across
all supported drivers.
====================

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

wifi: mac80211: restructure tx profile retrieval for MLO MBSSID

For MBSSID, each vif (struct ieee80211_vif) stores another vif
pointer for the transmitting profile of MBSSID set. This won't
suffice for MLO as there may be multiple links, each of which can
be part of different MBSSID sets. Hence the information needs to
be stored per-link. Additionally, the transmitted profile itself
may be part of an MLD hence storing vif will not suffice either.
Fix MLO by storing an instance of struct ieee80211_bss_conf
for each link.

Modify following operations to reflect the above structure updates:
- channel switch completion
- BSS color change completion
- Removing nontransmitted links in ieee80211_stop_mbssid()
- drivers retrieving the transmitted link for beacon templates.

Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Co-developed-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Co-developed-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Signed-off-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408184501.3715887-3-aloka.dixit@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: nl80211: add link id of transmitted profile for MLO MBSSID

During non-transmitted (nontx) profile configuration, interface
index of the transmitted (tx) profile is used to retrieve the
wireless device (wdev) associated with it. With MLO, this 'wdev'
may be part of an MLD with more than one link, hence only
interface index is not sufficient anymore to retrieve the correct
tx profile. Add a new attribute to configure link id of tx profile.

Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Co-developed-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Co-developed-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Signed-off-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408184501.3715887-2-aloka.dixit@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: ieee80211: Add helpers to fetch EMLSR delay and timeout values

Add helpers to get EMLSR transition delay, padding delay and transition
timeout values from EML capabilities field of Multi-link Element.

Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://patch.msgid.link/20250327051320.3253783-4-quic_ramess@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: update ML STA with EML capabilities

When an AP and Non-AP MLD operates in EMLSR mode, EML capabilities
advertised during Association contains information such as EMLSR
transition delay, padding delay and transition timeout values.

Save the EML capabilities information that is received during station
addition and capabilities update in ieee80211_sta so that drivers can use
it for triggering EMLSR operation.

Signed-off-by: Ramasamy Kaliappan <quic_rkaliapp@quicinc.com>
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://patch.msgid.link/20250327051320.3253783-3-quic_ramess@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: cfg80211: Add support to get EMLSR capabilities of non-AP MLD

The Enhanced multi-link single-radio (EMLSR) operation allows a non-AP MLD
with multiple receive chains to listen on one or more EMLSR links when the
corresponding non-AP STA(s) affiliated with the non-AP MLD is (are) in
the awake state. [IEEE 802.11be-2024, (35.3.17 Enhanced multi-link
single-radio (EMLSR) operation)]

An MLD which intends to enable EMLSR operations will set the EML
Capabilities Present subfield to 1 and shall set the EMLSR Support
subfield in the Common Info field of the Basic Multi-Link element to 1 in
all Management frames that include the Basic Multi-Link element except
Authentication frames. EML capabilities contains information such as
EML Transition timeout, Padding delay and Transition delay. These fields
needs to updated to drivers to trigger EMLSR operation and to transmit and
receive initial control frame and data frames.

Add support to receive EML Capabilities subfield that non-AP MLD
advertises during (re)association request and send it to underlying
drivers during ADD/SET station.

Signed-off-by: Ramasamy Kaliappan <quic_rkaliapp@quicinc.com>
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://patch.msgid.link/20250327051320.3253783-2-quic_ramess@quicinc.com
[accept EMLSR capabilities only for unassoc AP STA]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: VLAN traffic in multicast path

Currently for MLO, sending out multicast frames on each link is handled by
mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set.

Dynamic VLAN multicast traffic utilizes software encryption.
Due to this, mac80211 should handle transmitting multicast frames on
all links for multicast VLAN traffic.

Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Link: https://patch.msgid.link/20250325213125.1509362-4-muna.sinada@oss.qualcomm.com
[remove unnecessary parentheses]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: Create separate links for VLAN interfaces

Currently, MLD links for an AP_VLAN interface type is not fully
supported.

Add allocation of separate links for each VLAN interface and copy
chanctx and chandef of AP bss to VLAN where necessary. Separate
links are created because for Dynamic VLAN each link will have its own
default_multicast_key.

Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Link: https://patch.msgid.link/20250325213125.1509362-3-muna.sinada@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: Add link iteration macro for link data

Currently before iterating through valid links we are utilizing
open-coding when checking if vif valid_links is a non-zero value.

Add new macro, for_each_link_data(), which iterates through link_id
and checks if it is set on vif valid_links. If it is a valid link then
access link data for that link id.

Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Link: https://patch.msgid.link/20250325213125.1509362-2-muna.sinada@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: remove mwifiex_sta_init_cmd() last argument

The init argument from mwifiex_sta_init_cmd() is no longer used. Drop
it.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-4-1bb951073a06@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: drop asynchronous init waiting code

Historically all commands sent to the mwifiex driver have been
asynchronous. The different commands sent during driver initialization
have been queued at once and only the final command has been waited
for being ready before finally starting the driver.

This has been changed in Commit 7bff9c974e1a ("mwifiex: send firmware
initialization commands synchronously"). With this the initialization
is finished once the last mwifiex_send_cmd_sync() (now
mwifiex_send_cmd()) has returned. This makes all the code used to
wait for the last initialization command to be finished unnecessary,
so it's removed in this patch.

Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-3-1bb951073a06@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: let mwifiex_init_fw() return 0 for success

mwifiex_sta_init_cmd() returns -EINPROGRESS as success indication when
the init param is true. Likewise mwifiex_init_fw() returns -EINPROGRESS
as success indication: It will either return -EINPROGRESS directly when
in mfg_mode or the return value of mwifiex_sta_init_cmd() when in normal
mode.

-EINPROGRESS is a leftover from times when the initialization commands
were sent asynchronously. Since Commit 7bff9c974e1a ("mwifiex: send
firmware initialization commands synchronously") the return value has
become meaningless, so change mwifiex_sta_init_cmd() and
mwifiex_init_fw() to return 0 for success.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-2-1bb951073a06@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: remove unnecessary queue empty check

Since Commit 7bff9c974e1a ("mwifiex: send firmware initialization commands
synchronously") all initialization commands are sent synchronously which
means the command queue is empty when mwifiex_sta_init_cmd() returns. No
need to check for entries in the command code then, so remove the check.

Add a WARN_ON() just in case there is something wrong with the
reasoning.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-1-1bb951073a06@pengutronix.de
[remove now unused is_cmd_pend_q_empty variable and comment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: set step_urm in transport and not in the opmodes

This has nothing to do with the opmode. Set it in the transport layer
instead.

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

wifi: iwlwifi: mld: tests: simplify le32 bitfield handling

We can use le32_encode_bits() instead of cpu_to_le32()
combined with FIELD_PREP().

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

wifi: iwlwifi: update the PHY_CONTEXT_CMD API

A new field is added, no impact on the current flows.

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

wifi: iwlwifi: mld: inform trans on init failure

If starting the op mode failed, the opmode memory is being freed,
so trans->op_mode needs to be NULLified. Otherwise, trans will access
already freed memory.
Call iwl_trans_op_mode_leave in that case.

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

wifi: iwlwifi: mld: properly handle async notification in op mode start

From the moment that we have ALIVE, we can receive notification that
are handled asynchronously.

Some notifications (for example iwl_rfi_support_notif) requires an
operational FW. So we need to make sure that they were handled in
iwl_op_mode_mld_start before we stop the FW. Flush the async_handlers_wk
there to achieve that.

Also, if loading the FW in op mode start failed, we need to cancel
these notifications, as they are from a dead FW.

More than that, not doing so can cause us to access freed memory
if async_handlers_wk is executed after ieee80211_free_hw is called.

Fix this by canceling all async notifications if a failure occurred in
init (after ALIVE).

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250423091408.a8f63d983466.Ifd77d9c1a29fdd278b0a7bfc2709dd5d5e5efdb1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mld: refactor purging async notifications

To cancel all async notifications, we need to:
- cancel async_handlers_wk
- empty async_handlers_list

Instead of having the callers to do both, do it in
iwl_mld_purge_async_handlers_list and rename it accordingly.

Note that the caller iwl_cleanup_mld didn't cancel the work, but it is
harmless.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250423091408.e98aed77e836.Id9f858d9d553d406a24165b09db830df111befce@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mld: don't do iwl_trans_stop_device twice

If iwl_mld_load_fw failed, we call iwl_mld_stop_fw which does, among the
others, iwl_trans_stop_device. But this is already called from
iwl_mld_load_fw's error path.

Since we do need the other stuff of iwl_mld_stop_fw to be done also in
the error path of iwl_mld_load_fw, just call it there.

This also makes the call to iwl_fw_flush_dumps in
iwl_mld_op_mope_start redundant, since it is the same as iwl_fw_dbg_stop_sync.

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

wifi: iwlwifi: mld: stop hw if mcc_init fails

iwl_mld_run_fw_init_sequence used to be the last thing done in
iwl_mld_load_fw, and if it failed, it called iwl_trans_stop_hw.
Now we also have there iwl_mld_init_mcc, and it can fail.
In that case, we need to undo what we did so far, which is basically only
iwl_trans_stop_device. Do that.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250423091408.ba06d972a57b.I317fb7b10ed8a688a0d92c5d99de8765d8044b10@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mld: avoid memory leak if mcc_init fails

allocating mld->nvm_data used to be the last thing done in
iwl_mld_load_fw, so there was no need to free on any error path of
iwl_mld_load_fw.
But now iwl_mld_load_fw also calls iwl_mld_init_mcc, that can fail,
after allocating nvm->data. In that case, it is not freed.

As allocating the NVM data should only be done at op mode start anyway,
simply move it to there, where it is already freed in the right error
paths.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250423091408.d07469f866ac.I84ad2e624ce7cd4a661c73b4942186e50cdf82b2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mld: remove stored_beacon support

We never ask the firmware to store the beacon, so it won't ever send the
notification.
Remove the handling of that notification.
Remove that notification from the arrays of the notifications' names and
add the ones that we forgot to add.

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

wifi: iwlwifi: mld: remove P2P powersave tracking

Since the FW is tracking the CT window by itself, we don't need
to update the MAC context or even fill in the value. We just had
added that because a firmware bug had broken it for a while.

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://patch.msgid.link/20250423091408.ee164b464c21.I29de491b4d74b2b8084e54bfbd28646b15dee196@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: parse active and 20 MHz AP NVM channel flag

Configure 20 MHz AP mode based on NVM settings, set the
NL80211_RRF_ALLOW_20MHZ_ACTIVITY flag, when the NVM indicates
that an access point can operate in 20 MHz only.

Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250423091408.897d826a8612.I1f7f84f4485ed3928070c97a031110ccb608bda8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: re-add IWL_AMSDU_8K case

This case in iwl_trans_get_rb_size_order was accidently combined with
the IWL_AMSDU_12K case. Fix this.

Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250423091408.ef19205aa358.Ifbf89e7b7391cd7070267b7360c53230b3b2c57c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: fw: do reset handshake during assert if needed

Earlier, the firmware could only request the reset handshake is
done during the dump, if the dump was split. However, it's also
needed when the dump isn't split, in which case it must be done
before the dump. The firmware now advertises this requirement,
so do the handshake in the non-split case when asked for.

Rename apply policy ..._RESET_HANDSHAKE to ..._SPLIT_DUMP_RESET
to more clearly indicate that this specific dump needs to be
split, while the handshake requirement overall is now indicated
by the new capability flag.

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

wifi: iwlwifi: mvm: remove IWL_EMPTYING_HW_QUEUE_DELBA state

This state can never be entered, since the last place using it was
removed with non-DQA mode in commit c8f54701bdbf ("iwlwifi: mvm:
remove non-DQA mode"). Clean up this code too.

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

wifi: brcm80211: fmac: Add error log in brcmf_usb_dl_cmd()

In brcmf_usb_dl_cmd(), the error logging is not enough to describe
the error state. And some caller of the brcmf_usb_dl_cmd() does not
handle its error. An error log in brcmf_usb_dl_cmd() is needed to
prevent silent failure.

Add error handling in brcmf_usb_dl_cmd() to log the command id and
error code in the brcmf_usb_dl_cmd() fails. In this way, every
invocation of the function logs a message upon failure.

Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20250422065938.2345-1-vulab@iscas.ac.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: ieee80211: define beacon protection bit field

An AP supporting Beacon Protection should set bit 84 in
the extended capabilities IE (9.4.2.25 in the 802.11be D7 spec).
So the *4th* bit of the 10th byte should be checked to figure out
whether beacon protection is enabled or disabled.

Signed-off-by: Karthikeyan Kathirvel <karthikeyan.kathirvel@oss.qualcomm.com>
Reviewed-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20250421111505.3633992-1-karthikeyan.kathirvel@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: Don't use %pK through printk

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250417-restricted-pointers-wifi-v1-1-b79cdaae5579@linutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: brcmsmac: Spelling corrections

Various spelling corrections as flagged by codespell.

Signed-off-by: Simon Horman <horms@kernel.org>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20250415-brcmsmac-spell-v1-1-3e1375586883@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: move common settings out of switch/case

In mwifiex_add_virtual_intf() several settings done in a switch/case
are the same in all cases. Move them out of the switch/case to
deduplicate the code.

bss_started is not initialized in all switch/case branches, but it is
only used in AP mode in the driver, so it doesn't hurt to move its
initialization out of the switch/case as well.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Francesco Dolcini <francesco@dolcini.it>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-9-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: make locally used function static

mwifiex_is_tdls_off_chan() is only used locally. Make it static.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-8-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: fix indention

Align multiline if() under the opening brace.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-7-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: simplify mwifiex_setup_ht_caps()

In mwifiex_setup_ht_caps() first a local struct ieee80211_mcs_info
is initialized and afterwards copied over &ht_info->mcs. Simplify
this by initializing &ht_info->mcs directly.

While at it call memset on the u8 rx_mask[] array instead of the struct
which makes the intention clearer and we no longer have to assume the
rx_mask array is the first member of struct ieee80211_mcs_info.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-6-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: pass adapter to mwifiex_dnld_cmd_to_fw()

priv is not needed in mwifiex_dnld_cmd_to_fw(), so pass the adapter to
it as context pointer.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-5-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: make region_code_mapping_t const

region_code_mapping_t is not modified and shouldn't be. Mark it const.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-4-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: drop unnecessary initialization

Several functions initialize the priv * without actually using the
initialized value. Drop the initialization.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-3-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: use adapter as context pointer for mwifiex_hs_activated_event()

mwifiex_hs_activated_event() takes a struct mwifiex_private * as
context pointer which this function doesn't need directly and the callers
don't have. Use struct mwifiex_adapter * instead to simplify both the
function and the callers.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-2-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mwifiex: deduplicate code in mwifiex_cmd_tx_rate_cfg()

The code block inside the if/else is the same with just using
pbitmap_rates if non NULL or priv->bitmap_rates otherwise. Deduplicate
the code by picking the correct pointer first and then using it
unconditionally.

Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-1-a6bbd4ac4d37@pengutronix.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: Replace __get_unaligned_cpu32 in mesh_pathtbl.c

The __get_unaligned_cpu32 function is deprecated. So, replace it with
the more generic get_unaligned and just cast the input parameter.

Signed-off-by: Julian Vetter <julian@outer-limits.org>
Link: https://patch.msgid.link/20250408092220.2267754-1-julian@outer-limits.org
[fix subject]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

bcma: use new GPIO line value setter callbacks

struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patch.msgid.link/20250407-gpiochip-set-rv-bcma-v1-1-fa403ad76966@linaro.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Revert "mac80211: Dynamically set CoDel parameters per station"

This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel
parameter change essentially disables CoDel on slow stations, with some
questionable assumptions, as Dave pointed out in [0]. Quoting from
there:

  But here are my pithy comments as to why this part of mac80211 is so
  wrong...

   static void sta_update_codel_params(struct sta_info *sta, u32 thr)
   {
  -       if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {

  1) sta->local->num_sta is the number of associated, rather than
  active, stations. "Active" stations in the last 50ms or so, might have
  been a better thing to use, but as most people have far more than that
  associated, we end up with really lousy codel parameters, all the
  time. Mistake numero uno!

  2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.

  -               sta->cparams.target = MS2TIME(50);

  This, by itself, was probably not too bad. 30ms might have been
  better, at the time, when we were battling powersave etc, but 20ms was
  enough, really, to cover most scenarios, even where we had low rate
  2Ghz multicast to cope with. Even then, codel has a hard time finding
  any sane drop rate at all, with a target this high.

  -               sta->cparams.interval = MS2TIME(300);

  But this was horrible, a total mistake, that is leading to codel being
  completely ineffective in almost any scenario on clients or APS.
  100ms, even 80ms, here, would be vastly better than this insanity. I'm
  seeing 5+seconds of delay accumulated in a bunch of otherwise happily
  fq-ing APs....

  100ms of observed jitter during a flow is enough. Certainly (in 2016)
  there were interactions with powersave that I did not understand, and
  still don't, but if you are transmitting in the first place, powersave
  shouldn't be a problemmmm.....

  -               sta->cparams.ecn = false;

  At the time we were pretty nervous about ecn, I'm kind of sanguine
  about it now, and reliably indicating ecn seems better than turning it
  off for any reason.

  [...]

  In production, on p2p wireless, I've had 8ms and 80ms for target and
  interval for years now, and it works great.

I think Dave's arguments above are basically sound on the face of it,
and various experimentation with tighter CoDel parameters in the OpenWrt
community have show promising results[1]. So I don't think there's any
reason to keep this parameter fiddling; hence this revert.

[0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/
[1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130

Suggested-By: Dave Taht <dave.taht@gmail.com>
In-memory-of: Dave Taht <dave.taht@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: cfg80211/mac80211: remove more 5/10 MHz code

We still have ieee80211_chandef_rate_flags() and all that,
but all the users seem pretty much broken (deflink, etc.)
Remove all the code. It's been two years since last anyone
even vaguely entertained the notion of looking at this and
fixing it.

Link: https://patch.msgid.link/20250329221419.c31da7ae8c84.I1a3a4b6008134d66ca75a5bdfc004f4594da8145@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: Avoid -Wflex-array-member-not-at-end warning

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

Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.

So, with these changes, fix the following warning:

drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:6430:41: 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>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/Z-SV8gb6MuZJmmhe@kspp
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: mac80211: 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.

Use the `DEFINE_RAW_FLEX()` helper for on-stack definitions of
a flexible structure where the size of the flexible-array member
is known at compile-time, and refactor the rest of the code,
accordingly.

So, with these changes, fix the following warnings:

net/mac80211/spectmgmt.c:151:47: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
net/mac80211/spectmgmt.c:155:48: 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>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://patch.msgid.link/Z-SQdHZljwAgIlp9@kspp
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

dt-bindings: wireless: qcom,wcnss: Use wireless-controller.yaml

Reference wireless-controller.yaml schema, so we can use properties
as local-mac-address or mac-address.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-5-f5c3fe00e8f0@ixit.cz
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

dt-bindings: wireless: silabs,wfx: Use wireless-controller.yaml

Instead listing local-mac-address and mac-address properties, reference
wireless-controller.yaml schema. The schema brings in constraints for the
property checked during `make dtbs_check`.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-4-f5c3fe00e8f0@ixit.cz
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schema

The wireless-controller schema specifies local-mac-address as
used in the bcm4329-fmac device nodes of Apple silicon devices
(arch/arm64/boot/dts/apple).

Fixes `make dtbs_check` for those devices.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-3-f5c3fe00e8f0@ixit.cz
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

dt-bindings: net: Add generic wireless controller

Wireless controllers share the common properties.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-2-f5c3fe00e8f0@ixit.cz
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

dt-bindings: net: Add network-class schema for mac-address properties

The ethernet-controller schema specifies "mac-address" and
"local-mac-address" but other network devices such as wireless network
adapters use mac addresses as well.
The Devicetree Specification, Release v0.3 specifies in section 4.3.1
a generic "Network Class Binding" with "address-bits", "mac-address",
"local-mac-address" and "max-frame-size". This schema specifies the
"address-bits" property and moves the remaining properties over from
the ethernet-controller.yaml schema.

The "max-frame-size" property is used to describe the maximal payload
size despite its name. Keep the description from ethernet-controller
specifying this property as MTU. The contradictory description in the
Devicetree Specification is ignored.

Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-1-f5c3fe00e8f0@ixit.cz
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: fw: api: Absolute rudimentary typo fixes in the file power.h

s/folowing/following/
s/Celsuis/Celsius/
s/temerature/temperature/  ...twice

Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20210317042540.4097078-1-unixbhaskar@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0

The module metadata for the firmware file iwlwifi-Qu-c0-jf-b0-* is missing.

Signed-off-by: Víctor Gonzalo <victor.gonzalo@anddroptable.net>
Link: https://patch.msgid.link/20240313180227.2224780-1-victor.gonzalo@anddroptable.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: iwlwifi: mvm: Remove duplicated include in iwl-utils.c

The header files net/gso.h is included twice in iwl-utils.c,
so one inclusion of each can be removed.

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=13555
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250115005431.89510-1-yang.lee@linux.alibaba.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: free SKBTX_WIFI_STATUS skb tx_flags flag

Jason mentioned at netdevconf that we've run out of tx_flags in
the skb_shinfo(). Gain one bit back by removing the wifi bit.

We can do that because the only userspace application for it
(hostapd) doesn't change the setting on the socket, it just
uses different sockets, and normally doesn't even use this any
more, sending the frames over nl80211 instead.

Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Link: https://patch.msgid.link/20250313134942.52ff54a140ec.If390bbdc46904cf451256ba989d7a056c457af6e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

irqdomain: ssb: Switch to irq_domain_create_linear()

irq_domain_add_linear() is going away as being obsolete now. Switch to
the preferred irq_domain_create_linear(). That differs in the first
parameter: It takes more generic struct fwnode_handle instead of struct
device_node. Therefore, of_fwnode_handle() is added around the
parameter.

Note some of the users can likely use dev->fwnode directly instead of
indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
guaranteed to be set for all, so this has to be investigated on case to
case basis (by people who can actually test with the HW).

Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Michael Buesch <m@bues.ch>
Cc: linux-wireless@vger.kernel.org
Link: https://patch.msgid.link/20250319092951.37667-38-jirislaby@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: rt2x00: remove weird self-assignment in rt2800_loft_search()

Remove weird self-assignment in 'rt2800_loft_search()' assuming
that it was just a typo. Compile tested only.

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

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20250321134256.821596-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

wifi: wcn36xx: Don't use %pK through printk

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Acked-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-4-4e9a04dbe362@linutronix.de
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: Don't use %pK through printk

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-3-4e9a04dbe362@linutronix.de
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath11k: Don't use %pK through printk

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-2-4e9a04dbe362@linutronix.de
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath10k: Don't use %pK through printk

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.
There are still a few users of %pK left, but these use it through seq_file,
for which its usage is safe.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-1-4e9a04dbe362@linutronix.de
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: fix node corruption in ar->arvifs list

In current WLAN recovery code flow, ath12k_core_halt() only reinitializes
the "arvifs" list head. This will cause the list node immediately following
the list head to become an invalid list node. Because the prev of that node
still points to the list head "arvifs", but the next of the list head
"arvifs" no longer points to that list node.

When a WLAN recovery occurs during the execution of a vif removal, and it
happens before the spin_lock_bh(&ar->data_lock) in
ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned
situation, thereby triggering a kernel panic.

The fix is to remove and reinitialize all vif list nodes from the list head
"arvifs" during WLAN halt. The reinitialization is to make the list nodes
valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute
normally.

Call trace:
__list_del_entry_valid_or_report+0xd4/0x100 (P)
ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k]
ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k]
cfg80211_wiphy_work+0xfc/0x100
process_one_work+0x164/0x2d0
worker_thread+0x254/0x380
kthread+0xfc/0x100
ret_from_fork+0x10/0x20

The change is mostly copied from the ath11k patch:
https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250416021724.2162519-1-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash

Currently, we encounter the following kernel call trace when a firmware
crash occurs. This happens because the host sends WMI commands to the
firmware while it is in recovery, causing the commands to fail and
resulting in the kernel call trace.

Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the
host driver receives the firmware crash notification from MHI. This
prevents sending WMI commands to the firmware during recovery.

Call Trace:
 <TASK>
 dump_stack_lvl+0x75/0xc0
 register_lock_class+0x6be/0x7a0
 ? __lock_acquire+0x644/0x19a0
 __lock_acquire+0x95/0x19a0
 lock_acquire+0x265/0x310
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ? find_held_lock+0x34/0xa0
 ? ath12k_ce_send+0x56/0x210 [ath12k]
 _raw_spin_lock_bh+0x33/0x70
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_htc_send+0x178/0x390 [ath12k]
 ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k]
 ath12k_wmi_cmd_send+0x62/0x190 [ath12k]
 ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1
 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k]
 ieee80211_dump_survey+0x99/0x240 [mac80211]
 nl80211_dump_survey+0xe7/0x470 [cfg80211]
 ? kmalloc_reserve+0x59/0xf0
 genl_dumpit+0x24/0x70
 netlink_dump+0x177/0x360
 __netlink_dump_start+0x206/0x280
 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0
 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0
 ? genl_op_lock.part.12+0x10/0x10
 ? genl_dumpit+0x70/0x70
 genl_rcv_msg+0x1d0/0x290
 ? nl80211_del_station+0x330/0x330 [cfg80211]
 ? genl_get_cmd_both+0x50/0x50
 netlink_rcv_skb+0x4f/0x100
 genl_rcv+0x1f/0x30
 netlink_unicast+0x1b6/0x260
 netlink_sendmsg+0x31a/0x450
 __sock_sendmsg+0xa8/0xb0
 ____sys_sendmsg+0x1e4/0x260
 ___sys_sendmsg+0x89/0xe0
 ? local_clock_noinstr+0xb/0xc0
 ? rcu_is_watching+0xd/0x40
 ? kfree+0x1de/0x370
 ? __sys_sendmsg+0x7a/0xc0

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Fixes: a9b46dd2e483 ("wifi: ath12k: Add firmware coredump collection support")
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250416020414.2161545-1-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: avoid multiple skb_cb fetch in ath12k_mac_mgmt_tx_wmi()

ath12k_mac_mgmt_tx_wmi() fetches ath12k's skb_cb space multiple times from
TX skb which is redundant operation. Save the skb_cb in a local pointer
and use the same instead.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250415195812.2633923-3-rameshkumar.sundaram@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphers

Currently for CCMP256, GCMP128 and GCMP256 ciphers, in
ath12k_install_key() IEEE80211_KEY_FLAG_GENERATE_IV_MGMT is not set and
in ath12k_mac_mgmt_tx_wmi() a length of IEEE80211_CCMP_MIC_LEN is reserved
for all ciphers.

This results in unexpected drop of protected management frames in case
either of above 3 ciphers is used. The reason is, without
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT set, mac80211 will not generate
CCMP/GCMP headers in TX frame for ath12k.
Also MIC length reserved is wrong and such frames are dropped by hardware.

Fix this by setting IEEE80211_KEY_FLAG_GENERATE_IV_MGMT flag for above
ciphers and by reserving proper MIC length for those ciphers.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250415195812.2633923-2-rameshkumar.sundaram@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: Fix the QoS control field offset to build QoS header

Currently, in the mac80211 layer, received EAPOL packets are dropped
when the HT control field is present in the QoS header. This issue
arises due to an incorrect QoS control field offset used to build
the QoS header in the MSDU data, leading to a corrupted header in the
mac80211 layer. This issue also applies to other frames that contain
the QoS control field, such as QoS data or Null frames. To resolve
this, use ieee80211_get_qos_ctl() to obtain the correct QoS control
offset from the MSDU data. Additionally, ensure the QoS control header
is copied in little-endian format within the MSDU data.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Ramasamy Kaliappan <quic_rkaliapp@quicinc.com>
Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250415184102.2707300-1-nithyanantham.paramasivam@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: Avoid allocating rx_stats when ext_rx_stats is disabled

Currently, driver allocates the struct ath12k_rx_peer_stats for each
station regardless of whether ext_rx_stats is enabled. This structure
is populated by the monitor destination ring for both single-user and
multi-user scenarios when ext_rx_stats is enabled. However, when
ext_rx_stats is disabled, this allocation is unnecessary and results in
additional memory consumption.

To address this issue, allocate the struct ath12k_rx_peer_stats only when
ext_rx_stats is enabled through debugfs. This change prevents unnecessary
memory allocation. Additionally, ensure that the station dump RSSI is
updated irrespective of the ext_rx_stats enablement.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250409052647.81955-1-praneesh.p@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: avoid deadlock during regulatory update in ath12k_regd_update()

Running this test in a loop it is easy to reproduce an rtnl deadlock:

iw reg set FI
ifconfig wlan0 down

What happens is that thread A (workqueue) tries to update the regulatory:

    try to acquire the rtnl_lock of ar->regd_update_work

    rtnl_lock
    ath12k_regd_update [ath12k]
    ath12k_regd_update_work [ath12k]
    process_one_work
    worker_thread
    kthread
    ret_from_fork

And thread B (ifconfig) tries to stop the interface:

    try to cancel_work_sync(&ar->regd_update_work) in ath12k_mac_op_stop().
    ifconfig  3109 [003]  2414.232506: probe:

    ath12k_mac_op_stop [ath12k]
    drv_stop [mac80211]
    ieee80211_do_stop [mac80211]
    ieee80211_stop [mac80211]

The sequence of deadlock is:

1. Thread B calls rtnl_lock().

2. Thread A starts to run and calls rtnl_lock() from within
   ath12k_regd_update_work(), then enters wait state because the lock is
   owned by thread B.

3. Thread B tries to call cancel_work_sync(&ar->regd_update_work), but
   thread A is in ath12k_regd_update_work() waiting for rtnl_lock(). So
   cancel_work_sync() forever waits for ath12k_regd_update_work() to
   finish and we have a deadlock.

Change to use regulatory_set_wiphy_regd(), which is the asynchronous
version of regulatory_set_wiphy_regd_sync(). This way rtnl & wiphy locks
are not required so can be removed, and in the end the deadlock issue can
be avoided.

But a side effect introduced by the asynchronous regd update is that,
some essential information used in ath12k_reg_update_chan_list(), which
would be called later in ath12k_regd_update(), might has not been updated
by cfg80211, as a result wrong channel parameters sent to firmware.

To handle this side effect, move ath12k_reg_update_chan_list() to
ath12k_reg_notifier(), and advertise WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER
to cfg80211. This works because, in the process of the asynchronous regd
update, after the new regd is processed, cfg80211 will notify ath12k by
calling ath12k_reg_notifier(). Since all essential information is updated
at that time, we are good to do channel list update.

Please note ath12k_reg_notifier() could also be called due to other
reasons, like core/beacon/user hints etc. For them we are not allowed to
call ath12k_reg_update_chan_list() because regd has not been updated.
This is done by verifying  the initiator.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Co-developed-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408-rtnl-deadlock-v3-1-fdc12bc511ea@quicinc.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: Add MSDU length validation for TKIP MIC error

In the WBM error path, while processing TKIP MIC errors, MSDU length
is fetched from the hal_rx_desc's msdu_end. This MSDU length is
directly passed to skb_put() without validation. In stress test
scenarios, the WBM error ring may receive invalid descriptors, which
could lead to an invalid MSDU length.

To fix this, add a check to drop the skb when the calculated MSDU
length is greater than the skb size.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>

wifi: ath12k: fix invalid access to memory

In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean
is_continuation is part of rxcb.
Currently, after freeing the skb, the rxcb->is_continuation accessed
again which is wrong since the memory is already freed.
This might lead use-after-free error.

Hence, fix by locally defining bool is_continuation from rxcb,
so that after freeing skb, is_continuation can be used.

Compile tested only.

Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250408045327.1632222-1-quic_sarishar@quicinc.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>