* [PATCH iwlwifi-next 09/15] wifi: iwlwifi: mld: rename LINK_DEBUGFS_WRITE_FILE_OPS
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
These are with wiphy mutex held, so rename the macro to
LINK_DEBUGFS_WIPHY_WRITE_FILE_OPS indicating that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
tested: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mld/debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/debugfs.c b/drivers/net/wireless/intel/iwlwifi/mld/debugfs.c
index ba5a47519aa1..afe972834cb8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/debugfs.c
@@ -979,7 +979,8 @@ void iwl_mld_add_vif_debugfs(struct ieee80211_hw *hw,
VIF_DEBUGFS_ADD_FILE(twt_operation, mld_vif_dbgfs, 0200);
VIF_DEBUGFS_ADD_FILE(int_mlo_scan, mld_vif_dbgfs, 0200);
}
-#define LINK_DEBUGFS_WRITE_FILE_OPS(name, bufsz) \
+
+#define LINK_DEBUGFS_WIPHY_WRITE_FILE_OPS(name, bufsz) \
WIPHY_DEBUGFS_WRITE_FILE_OPS(link_##name, bufsz, bss_conf)
#define LINK_DEBUGFS_ADD_FILE_ALIAS(alias, name, parent, mode) \
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 08/15] wifi: iwlwifi: mld: Disallow using a per-STA GTK for Tx
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Ilan Peer, Johannes Berg
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Ilan Peer <ilan.peer@intel.com>
When a GTK is configured for a station, it can only be used for Rx
and never for Tx. In such a case, set the IWL_SEC_KEY_FLAG_NO_TX
flag when the key is installed, so the FW will not use it for Tx.
Specifically, this is needed for per-station GTK installed on NAN
NDI stations associated with NAN Data interfaces.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
tested: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mld/key.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/key.c b/drivers/net/wireless/intel/iwlwifi/mld/key.c
index a6454d90d0e3..bf80b4770b5a 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/key.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/key.c
@@ -49,6 +49,12 @@ static u32 iwl_mld_get_key_flags(struct iwl_mld *mld,
if (key->flags & IEEE80211_KEY_FLAG_SPP_AMSDU)
flags |= IWL_SEC_KEY_FLAG_SPP_AMSDU;
+ /* When a GTK is configured for a station, it can only be
+ * used for Rx and never for Tx. Thus, set the NO TX flag.
+ */
+ if (!pairwise && sta)
+ flags |= IWL_SEC_KEY_FLAG_NO_TX;
+
return flags;
}
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 07/15] wifi: iwlwifi: print UHR rate type
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Gabay
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Daniel Gabay <daniel.gabay@intel.com>
Log "UHR" in rs_pretty_print_rate() instead of "Unknown".
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/fw/rs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/rs.c b/drivers/net/wireless/intel/iwlwifi/fw/rs.c
index 746f2acffb8f..2aa300b26158 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/rs.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/*
- * Copyright (C) 2021-2022, 2025 Intel Corporation
+ * Copyright (C) 2021-2022, 2025-2026 Intel Corporation
*/
#include <net/mac80211.h>
@@ -124,6 +124,9 @@ int rs_pretty_print_rate(char *buf, int bufsz, const u32 rate)
case RATE_MCS_MOD_TYPE_EHT:
type = "EHT";
break;
+ case RATE_MCS_MOD_TYPE_UHR:
+ type = "UHR";
+ break;
default:
type = "Unknown"; /* shouldn't happen */
}
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 06/15] wifi: iwlwifi: reduce the log level of firmware debug buffer size mismatch
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This is not really an error and we can safely reduce the log level to
INFO.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
index e3603571bdd9..50342604491d 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
@@ -141,10 +141,10 @@ static void iwl_pcie_alloc_fw_monitor_block(struct iwl_trans *trans,
return;
if (power != max_power)
- IWL_ERR(trans,
- "Sorry - debug buffer is only %luK while you requested %luK\n",
- (unsigned long)BIT(power - 10),
- (unsigned long)BIT(max_power - 10));
+ IWL_INFO(trans,
+ "Sorry - debug buffer is only %luK while you requested %luK\n",
+ (unsigned long)BIT(power - 10),
+ (unsigned long)BIT(max_power - 10));
fw_mon->block = block;
fw_mon->physical = physical;
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 05/15] wifi: iwlwifi: mld: evacuate NAN channels on link switch
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
The FW API doesn't allow a station (of certain types, including
STATION_TYPE_PEER) to not be correlated to any link. Therefore,
when switching links, mac80211 first adds the new link and then
removes the old one.
In case we have a NAN interface that operates on 3 links and a
BSS interface that operates on the 4th link, there won't be any
room to perform a link switch that temporarily needs two links
for the BSS interface, but the firmware only has four total.
To mitigate this, try to evacuate a NAN channel in this scenario:
First try to evacuate a NAN channel using the same phy as the BSS
link being deactivated, since we expect NAN to follow the BSS
channel configuration. If that doesn't work, try to evacuate any
NAN channel.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
.../net/wireless/intel/iwlwifi/mld/mac80211.c | 95 ++++++++++++++++++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 9dc540720ecd..92858b8f7395 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -2585,15 +2585,108 @@ iwl_mld_mac80211_mgd_protect_tdls_discover(struct ieee80211_hw *hw,
ret);
}
+static int iwl_mld_count_free_link_ids(struct iwl_mld *mld)
+{
+ int free_count = 0;
+
+ for (int i = 0; i < mld->fw->ucode_capa.num_links; i++) {
+ if (!rcu_access_pointer(mld->fw_id_to_bss_conf[i]))
+ free_count++;
+ }
+
+ return free_count;
+}
+
+static bool
+iwl_mld_chanctx_used_by_other_vif(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_chanctx_conf *chanctx_conf)
+{
+ struct ieee80211_bss_conf *iter_link;
+ struct ieee80211_vif *iter_vif;
+ int link_id;
+
+ for_each_active_interface(iter_vif, hw) {
+ if (vif == iter_vif)
+ continue;
+
+ /* NAN doesn't have active links, so we don't count NAN users */
+ for_each_vif_active_link(iter_vif, iter_link, link_id) {
+ if (rcu_access_pointer(iter_link->chanctx_conf) ==
+ chanctx_conf)
+ return true;
+ }
+ }
+
+ return false;
+}
+
static bool iwl_mld_can_activate_links(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
u16 desired_links)
{
struct iwl_mld *mld = IWL_MAC80211_GET_MLD(hw);
int n_links = hweight16(desired_links);
+ int n_add = hweight16(desired_links & ~vif->active_links);
+ unsigned long to_deactivate = vif->active_links & ~desired_links;
+ int free_link_ids;
+ int i;
/* Check if HW supports the wanted number of links */
- return n_links <= iwl_mld_max_active_links(mld, vif);
+ if (n_links > iwl_mld_max_active_links(mld, vif))
+ return false;
+
+ /*
+ * During link switch, mac80211 first adds the new links, then removes
+ * the old ones. This means we temporarily need extra link objects
+ * during the transition. Check if we have enough free link IDs.
+ */
+
+ free_link_ids = iwl_mld_count_free_link_ids(mld);
+
+ if (free_link_ids >= n_add)
+ return true;
+
+ if (!mld->nan_device_vif)
+ return false;
+
+ /*
+ * Not enough free link IDs. First try to evacuate NAN from the
+ * channel context of a link that is going to be deactivated.
+ */
+ for_each_set_bit(i, &to_deactivate, IEEE80211_MLD_MAX_NUM_LINKS) {
+ struct ieee80211_bss_conf *link_conf;
+ struct ieee80211_chanctx_conf *chanctx_conf;
+
+ link_conf = link_conf_dereference_protected(vif, i);
+ if (!link_conf)
+ continue;
+
+ chanctx_conf = wiphy_dereference(mld->wiphy, link_conf->chanctx_conf);
+ if (!chanctx_conf)
+ continue;
+
+ if (iwl_mld_chanctx_used_by_other_vif(hw, vif, chanctx_conf))
+ continue;
+
+ if (ieee80211_nan_try_evacuate(hw, chanctx_conf)) {
+ free_link_ids = iwl_mld_count_free_link_ids(mld);
+ /*
+ * Evacuation of one channel should do the job. If not,
+ * something bad is happening. Don't try to evacuate more
+ */
+ return free_link_ids >= n_add;
+ }
+ }
+
+ /* Couldn't find/evacuate any channel going to go unused, try any */
+ if (ieee80211_nan_try_evacuate(hw, NULL)) {
+ free_link_ids = iwl_mld_count_free_link_ids(mld);
+ if (free_link_ids >= n_add)
+ return true;
+ }
+
+ return false;
}
static int
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 04/15] wifi: iwlwifi: mld: implement UHR multi-link PM
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Emmanuel Grumbach
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
For multi-link power management, the driver really only needs
to advertise the capability and tell the firmware that the AP
has it. Implement this.
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>
---
drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 2 ++
drivers/net/wireless/intel/iwlwifi/mld/link.c | 5 +++++
drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 2 ++
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
index dd69687a4e48..09b2cddc4ad2 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
@@ -556,6 +556,7 @@ enum iwl_link_ctx_protection_flags {
* of threshold
* @LINK_FLG_NPCA: NPCA enabled
* @LINK_FLG_DPS: AP is a DPS assisting AP
+ * @LINK_FLG_MLPM: AP supports UHR multi-link PM
* @LINK_FLG_DUO: AP supports UHR DUO
*/
enum iwl_link_ctx_flags {
@@ -565,6 +566,7 @@ enum iwl_link_ctx_flags {
LINK_FLG_NDP_FEEDBACK_ENABLED = BIT(3),
LINK_FLG_NPCA = BIT(4),
LINK_FLG_DPS = BIT(6),
+ LINK_FLG_MLPM = BIT(7),
LINK_FLG_DUO = BIT(8),
}; /* LINK_CONTEXT_FLAG_E_VER_1 */
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/link.c b/drivers/net/wireless/intel/iwlwifi/mld/link.c
index 4ac2740dd8a1..e5e9b7089c14 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/link.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/link.c
@@ -352,6 +352,11 @@ iwl_mld_change_link_in_fw(struct iwl_mld *mld, struct ieee80211_bss_conf *link,
link_sta->uhr_cap.mac.mac_cap[1] &
IEEE80211_UHR_MAC_CAP1_DUO_SUPP)
flags |= LINK_FLG_DUO;
+
+ if (link_sta->uhr_cap.has_uhr &&
+ mld_vif->ap_sta->ext_mld_capa_ops &
+ IEEE80211_UHR_ML_EXT_MLD_CAPA_ML_PM)
+ flags |= LINK_FLG_MLPM;
}
cmd.htc_trig_based_pkt_ext = link->htc_trig_based_pkt_ext;
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 9736b43155d6..9dc540720ecd 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -420,6 +420,8 @@ static void iwl_mac_hw_set_wiphy(struct iwl_mld *mld)
mld->ext_capab[0].eml_capabilities = IWL_MLD_EMLSR_CAPA;
mld->ext_capab[0].mld_capa_and_ops = IWL_MLD_CAPA_OPS;
+ mld->ext_capab[0].ext_mld_capa_and_ops =
+ IEEE80211_UHR_ML_EXT_MLD_CAPA_ML_PM;
}
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 03/15] wifi: iwlwifi: mld: add UHR DUO support
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Emmanuel Grumbach
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
The firmware needs to know whether or not DUO (assisting) is
supported by the AP, and we should claim DUO support ourselves.
Implement this.
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>
---
drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h | 2 ++
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 1 +
drivers/net/wireless/intel/iwlwifi/mld/link.c | 5 +++++
3 files changed, 8 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
index 09f869b5be0c..dd69687a4e48 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
@@ -556,6 +556,7 @@ enum iwl_link_ctx_protection_flags {
* of threshold
* @LINK_FLG_NPCA: NPCA enabled
* @LINK_FLG_DPS: AP is a DPS assisting AP
+ * @LINK_FLG_DUO: AP supports UHR DUO
*/
enum iwl_link_ctx_flags {
LINK_FLG_BSS_COLOR_DIS = BIT(0),
@@ -564,6 +565,7 @@ enum iwl_link_ctx_flags {
LINK_FLG_NDP_FEEDBACK_ENABLED = BIT(3),
LINK_FLG_NPCA = BIT(4),
LINK_FLG_DPS = BIT(6),
+ LINK_FLG_DUO = BIT(8),
}; /* LINK_CONTEXT_FLAG_E_VER_1 */
/**
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index f29de029c709..7027bca249a0 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -698,6 +698,7 @@ static const struct ieee80211_sband_iftype_data iwl_iftype_cap[] = {
.mac.mac_cap = {
[0] = IEEE80211_UHR_MAC_CAP0_NPCA_SUPP |
IEEE80211_UHR_MAC_CAP0_DPS_SUPP,
+ [1] = IEEE80211_UHR_MAC_CAP1_DUO_SUPP,
},
},
},
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/link.c b/drivers/net/wireless/intel/iwlwifi/mld/link.c
index 3c1825ba2b86..4ac2740dd8a1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/link.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/link.c
@@ -347,6 +347,11 @@ iwl_mld_change_link_in_fw(struct iwl_mld *mld, struct ieee80211_bss_conf *link,
link_sta->uhr_cap.mac.mac_cap[0] &
IEEE80211_UHR_MAC_CAP0_DPS_ASSIST_SUPP)
flags |= LINK_FLG_DPS;
+
+ if (link_sta->uhr_cap.has_uhr &&
+ link_sta->uhr_cap.mac.mac_cap[1] &
+ IEEE80211_UHR_MAC_CAP1_DUO_SUPP)
+ flags |= LINK_FLG_DUO;
}
cmd.htc_trig_based_pkt_ext = link->htc_trig_based_pkt_ext;
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 02/15] wifi: iwlwifi: mld: add support for deferred nan schedule config
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Avraham Stern
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Avraham Stern <avraham.stern@intel.com>
Add support for deferred schedule update. Notify mac80211 that the
schedule update is done when the firmware notifies that the schedule
is applied.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
.../wireless/intel/iwlwifi/fw/api/mac-cfg.h | 29 +++++++++++++
drivers/net/wireless/intel/iwlwifi/mld/mld.c | 1 +
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 43 +++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/mld/nan.h | 5 +++
.../net/wireless/intel/iwlwifi/mld/notif.c | 4 ++
5 files changed, 82 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
index d03a2bda4e68..09f869b5be0c 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/mac-cfg.h
@@ -84,6 +84,11 @@ enum iwl_mac_conf_subcmd_ids {
* @NAN_ULW_ATTR_NOTIF: &struct iwl_nan_ulw_attr_notif
*/
NAN_ULW_ATTR_NOTIF = 0xf2,
+ /**
+ * @NAN_SCHED_UPDATE_COMPLETED_NOTIF:
+ * &struct iwl_nan_sched_update_completed_notif
+ */
+ NAN_SCHED_UPDATE_COMPLETED_NOTIF = 0xf3,
/**
* @NAN_DW_END_NOTIF: &struct iwl_nan_dw_end_notif
*/
@@ -1421,4 +1426,28 @@ struct iwl_nan_ulw_attr_notif {
u8 attr[IWL_NAN_MAX_ENDLESS_ULW_ATTR_LEN];
} __packed; /* NAN_ULW_ATTR_NOTIF_API_S_VER_1 */
+/**
+ * enum iwl_nan_sched_update_status - NAN schedule update status
+ *
+ * @IWL_NAN_SCHED_UPDATE_SUCCESS: schedule update completed successfully
+ * @IWL_NAN_SCHED_UPDATE_FAILURE: schedule update failed. Currently not expected
+ * to happen, but reserved for future use.
+ */
+enum iwl_nan_sched_update_status {
+ IWL_NAN_SCHED_UPDATE_SUCCESS = 0,
+ IWL_NAN_SCHED_UPDATE_FAILURE = 1,
+};
+
+/**
+ * struct iwl_nan_sched_update_completed_notif - NAN schedule update completed
+ *
+ * @status: status of the schedule update operation. See
+ * &enum iwl_nan_sched_update_status
+ * @reserved: reserved
+ */
+struct iwl_nan_sched_update_completed_notif {
+ u8 status;
+ u8 reserved[3];
+} __packed; /* NAN_SCHED_UPDATE_COMPLETED_NTF_API_S_VER_1 */
+
#endif /* __iwl_fw_api_mac_cfg_h__ */
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mld.c b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
index 054bb1134425..0ef7c24831d8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mld.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
@@ -238,6 +238,7 @@ static const struct iwl_hcmd_names iwl_mld_mac_conf_names[] = {
HCMD_NAME(NAN_SCHEDULE_CMD),
HCMD_NAME(NAN_PEER_CMD),
HCMD_NAME(NAN_ULW_ATTR_NOTIF),
+ HCMD_NAME(NAN_SCHED_UPDATE_COMPLETED_NOTIF),
HCMD_NAME(NAN_DW_END_NOTIF),
HCMD_NAME(NAN_JOINED_CLUSTER_NOTIF),
HCMD_NAME(MISSED_BEACONS_NOTIF),
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/nan.c b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
index d13b2374b642..d34a9a2cbeae 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/nan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
@@ -689,11 +689,20 @@ void iwl_mld_nan_vif_cfg_changed(struct iwl_mld *mld,
switch (version) {
case 1:
+ if (sched_cfg->deferred) {
+ IWL_ERR(mld,
+ "NAN: deferred schedule not supported by FW\n");
+ return;
+ }
+
cmd_size = sizeof(struct iwl_nan_schedule_cmd_v1);
break;
case 2:
cmd_size = sizeof(struct iwl_nan_schedule_cmd);
+ if (sched_cfg->deferred)
+ cmd.deferred = 1;
+
if (sched_cfg->avail_blob_len &&
!WARN_ON(sched_cfg->avail_blob_len >
sizeof(cmd.avail_attr.attr))) {
@@ -869,6 +878,40 @@ void iwl_mld_nan_vif_cfg_changed(struct iwl_mld *mld,
}
}
+bool iwl_mld_cancel_nan_sched_update_completed_notif(struct iwl_mld *mld,
+ struct iwl_rx_packet *pkt,
+ u32 obj_id)
+{
+ return true;
+}
+
+void iwl_mld_handle_nan_sched_update_completed_notif(struct iwl_mld *mld,
+ struct iwl_rx_packet *pkt)
+{
+ struct iwl_nan_sched_update_completed_notif *notif = (void *)pkt->data;
+ struct ieee80211_vif *vif = mld->nan_device_vif;
+
+ if (IWL_FW_CHECK(mld, !vif,
+ "NAN: schedule update completed without NAN vif\n"))
+ return;
+
+ if (IWL_FW_CHECK(mld, !ieee80211_vif_nan_started(vif),
+ "NAN: schedule update completed without NAN started\n"))
+ return;
+
+ /*
+ * Deferred schedule update should not fail in firmware since all
+ * channels and links were added.
+ */
+ IWL_FW_CHECK(mld, notif->status != IWL_NAN_SCHED_UPDATE_SUCCESS,
+ "NAN: deferred schedule update failed\n");
+
+ if (WARN_ON(!vif->cfg.nan_sched.deferred))
+ return;
+
+ ieee80211_nan_sched_update_done(vif);
+}
+
int iwl_mld_mac802111_nan_peer_sched_changed(struct ieee80211_hw *hw,
struct ieee80211_sta *sta)
{
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/nan.h b/drivers/net/wireless/intel/iwlwifi/mld/nan.h
index f4e4cd4b4e8d..5411bca52cde 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/nan.h
+++ b/drivers/net/wireless/intel/iwlwifi/mld/nan.h
@@ -42,6 +42,8 @@ void iwl_mld_handle_nan_ulw_attr_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt);
void iwl_mld_handle_nan_dw_end_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt);
+void iwl_mld_handle_nan_sched_update_completed_notif(struct iwl_mld *mld,
+ struct iwl_rx_packet *pkt);
bool iwl_mld_cancel_nan_cluster_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt,
u32 obj_id);
@@ -51,6 +53,9 @@ bool iwl_mld_cancel_nan_ulw_attr_notif(struct iwl_mld *mld,
bool iwl_mld_cancel_nan_dw_end_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt,
u32 obj_id);
+bool iwl_mld_cancel_nan_sched_update_completed_notif(struct iwl_mld *mld,
+ struct iwl_rx_packet *pkt,
+ u32 obj_id);
void iwl_mld_nan_vif_cfg_changed(struct iwl_mld *mld,
struct ieee80211_vif *vif,
u64 changes);
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/notif.c b/drivers/net/wireless/intel/iwlwifi/mld/notif.c
index a5074bbc7e24..d7383022a0ed 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/notif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/notif.c
@@ -348,6 +348,8 @@ CMD_VERSIONS(beacon_filter_notif, CMD_VER_ENTRY(2, iwl_beacon_filter_notif))
CMD_VERSIONS(nan_cluster_notif, CMD_VER_ENTRY(1, iwl_nan_cluster_notif))
CMD_VERSIONS(nan_ulw_attr_notif, CMD_VER_ENTRY(1, iwl_nan_ulw_attr_notif))
CMD_VERSIONS(nan_dw_end_notif, CMD_VER_ENTRY(1, iwl_nan_dw_end_notif))
+CMD_VERSIONS(nan_sched_update_completed_notif,
+ CMD_VER_ENTRY(1, iwl_nan_sched_update_completed_notif))
DEFINE_SIMPLE_CANCELLATION(session_prot, iwl_session_prot_notif, mac_link_id)
DEFINE_SIMPLE_CANCELLATION(tlc, iwl_tlc_update_notif, sta_id)
@@ -468,6 +470,8 @@ const struct iwl_rx_handler iwl_mld_rx_handlers[] = {
nan_ulw_attr_notif)
RX_HANDLER_OF_NAN(MAC_CONF_GROUP, NAN_DW_END_NOTIF,
nan_dw_end_notif)
+ RX_HANDLER_OF_NAN(MAC_CONF_GROUP, NAN_SCHED_UPDATE_COMPLETED_NOTIF,
+ nan_sched_update_completed_notif)
};
EXPORT_SYMBOL_IF_IWLWIFI_KUNIT(iwl_mld_rx_handlers);
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 01/15] wifi: iwlwifi: mld: nan: add availability attribute to schedule config
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Avraham Stern
In-Reply-To: <20260514194434.401241-1-miriam.rachel.korenblit@intel.com>
From: Avraham Stern <avraham.stern@intel.com>
Add the availability attribute to the schedule config command. The
firmware needs to add this attribute to schedule update frames
(e.g. when ULW changed or the local schedule changed).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/nan.c b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
index 530ba263c5f0..d13b2374b642 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/nan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
@@ -693,6 +693,14 @@ void iwl_mld_nan_vif_cfg_changed(struct iwl_mld *mld,
break;
case 2:
cmd_size = sizeof(struct iwl_nan_schedule_cmd);
+
+ if (sched_cfg->avail_blob_len &&
+ !WARN_ON(sched_cfg->avail_blob_len >
+ sizeof(cmd.avail_attr.attr))) {
+ cmd.avail_attr.attr_len = sched_cfg->avail_blob_len;
+ memcpy(cmd.avail_attr.attr, sched_cfg->avail_blob,
+ sched_cfg->avail_blob_len);
+ }
break;
default:
IWL_ERR(mld, "NAN: unsupported NAN schedule cmd version %d\n",
@@ -727,6 +735,15 @@ void iwl_mld_nan_vif_cfg_changed(struct iwl_mld *mld,
BUILD_BUG_ON(ARRAY_SIZE(sched_cfg->channels) !=
ARRAY_SIZE(cmd.channels));
+ /*
+ * mac80211 removes unused channels before adding new ones, so it may
+ * update an empty schedule with an availability attribute because it
+ * is going to add channels later. Since the firmware does not expect
+ * an availability attribute without channels, ignore it in that case.
+ */
+ if (empty_schedule)
+ cmd.avail_attr.attr_len = 0;
+
/* find links we can keep (same chanctx/PHY) */
for (i = 0; i < ARRAY_SIZE(sched_cfg->channels); i++) {
struct ieee80211_chanctx_conf *chanctx;
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 00/15] wifi: iwlwifi: updates - 2026-05-14
From: Miri Korenblit @ 2026-05-14 19:44 UTC (permalink / raw)
To: linux-wireless
Hi,
features, fixes and cleanups from our internal tree.
Thanks,
Miri
---
Avraham Stern (2):
wifi: iwlwifi: mld: nan: add availability attribute to schedule config
wifi: iwlwifi: mld: add support for deferred nan schedule config
Daniel Gabay (1):
wifi: iwlwifi: print UHR rate type
Emmanuel Grumbach (1):
wifi: iwlwifi: reduce the log level of firmware debug buffer size
mismatch
Ilan Peer (1):
wifi: iwlwifi: mld: Disallow using a per-STA GTK for Tx
Johannes Berg (7):
wifi: iwlwifi: mld: add UHR DUO support
wifi: iwlwifi: mld: implement UHR multi-link PM
wifi: iwlwifi: mld: rename LINK_DEBUGFS_WRITE_FILE_OPS
wifi: iwlwifi: mld: add link and link station FW IDs to debugfs
wifi: iwlwifi: api: remove NAN_GROUP
wifi: iwlwifi: api: clean up/fix some kernel-doc references
wifi: iwlwifi: pcie: add two LNL PCI IDs
Miri Korenblit (1):
wifi: iwlwifi: mld: evacuate NAN channels on link switch
Pagadala Yesu Anjaneyulu (1):
wifi: iwlwifi: mld: disallow puncturing in US/CA for WH
Shahar Tzarfati (1):
wifi: iwlwifi: mld: expose beacon avg signal
.../wireless/intel/iwlwifi/fw/api/commands.h | 9 +-
.../wireless/intel/iwlwifi/fw/api/location.h | 7 +-
.../wireless/intel/iwlwifi/fw/api/mac-cfg.h | 33 +++++++
drivers/net/wireless/intel/iwlwifi/fw/rs.c | 5 +-
.../wireless/intel/iwlwifi/iwl-nvm-parse.c | 1 +
.../net/wireless/intel/iwlwifi/mld/debugfs.c | 53 +++++++++-
drivers/net/wireless/intel/iwlwifi/mld/key.c | 6 ++
drivers/net/wireless/intel/iwlwifi/mld/link.c | 10 ++
drivers/net/wireless/intel/iwlwifi/mld/link.h | 3 +
.../net/wireless/intel/iwlwifi/mld/mac80211.c | 97 ++++++++++++++++++-
drivers/net/wireless/intel/iwlwifi/mld/mcc.c | 13 ++-
drivers/net/wireless/intel/iwlwifi/mld/mld.c | 1 +
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 60 ++++++++++++
drivers/net/wireless/intel/iwlwifi/mld/nan.h | 5 +
.../net/wireless/intel/iwlwifi/mld/notif.c | 4 +
.../net/wireless/intel/iwlwifi/mld/stats.c | 47 ++++++++-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 +
.../intel/iwlwifi/pcie/gen1_2/trans.c | 8 +-
18 files changed, 344 insertions(+), 20 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH] wifi: mt76: Use IS_ERR() check for mt76_register_debugfs_fops()
From: Ingyu Jang @ 2026-05-14 19:32 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, linux-arm-kernel,
linux-mediatek, linux-kernel
mt76_register_debugfs_fops() returns the dentry from
debugfs_create_dir(), which yields an error pointer on failure and
never NULL. The NULL checks in the per-chip *_init_debugfs() helpers
are therefore unreachable, and on a real failure the ERR_PTR would
be returned to callers as a valid pointer.
Use IS_ERR() and propagate the actual error via PTR_ERR() in
mt7615/mt7915/mt7921/mt7925/mt7996.
Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
---
drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c | 4 ++--
drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c | 4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
index 0f7b20152279c..5c3646a67e4b7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c
@@ -550,8 +550,8 @@ int mt7615_init_debugfs(struct mt7615_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (is_mt7615(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues", dir,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
index 26ed3745af43e..f62a17c8958ac 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c
@@ -1296,8 +1296,8 @@ int mt7915_init_debugfs(struct mt7915_phy *phy)
struct dentry *dir;
dir = mt76_register_debugfs_fops(phy->mt76, NULL);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
debugfs_create_file("muru_debug", 0600, dir, dev, &fops_muru_debug);
debugfs_create_file("muru_stats", 0400, dir, phy,
&mt7915_muru_stats_fops);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
index 4333005b3ad95..4da339867b6a7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
@@ -266,8 +266,8 @@ int mt7921_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
index e2498659c884e..01aa4a1071fdd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/debugfs.c
@@ -291,8 +291,8 @@ int mt7925_init_debugfs(struct mt792x_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, &fops_regval);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
if (mt76_is_mmio(&dev->mt76))
debugfs_create_devm_seqfile(dev->mt76.dev, "xmit-queues",
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
index 34af800964d11..63cd490977106 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/debugfs.c
@@ -875,8 +875,8 @@ int mt7996_init_debugfs(struct mt7996_dev *dev)
struct dentry *dir;
dir = mt76_register_debugfs_fops(&dev->mphy, NULL);
- if (!dir)
- return -ENOMEM;
+ if (IS_ERR(dir))
+ return PTR_ERR(dir);
debugfs_create_file("hw-queues", 0400, dir, dev,
&mt7996_hw_queues_fops);
--
2.34.1
^ permalink raw reply related
* Re: [RFT rtw/rtw-next] wifi: rtw88: check if center channel is supported before setting
From: Thadeu Lima de Souza Cascardo @ 2026-05-14 17:41 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless, kevin_yang
In-Reply-To: <20260413053601.13037-1-pkshih@realtek.com>
On Mon, Apr 13, 2026 at 01:36:01PM +0800, Ping-Ke Shih wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> Some unusual center channels may be assigned to driver. However, RF
> doesn't really expect them, and then warnings happen due to lack of
> TX power limit configurations. For example, center channel 114/130
> with 80MHz. So, add a check before setting the channel.
>
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Hi,
I have tested this patch and it does prevent 80MHz from being used.
However, RF seems to accept those center channels with 80MHz just fine. I
can get up to 600Mbps with UDP while I can get past 300Mbps after applying
this patch.
Should we apply something like [1] instead?
https://lore.kernel.org/linux-wireless/20260306-rtw88_channel130-v1-1-ff25a5bc930a@igalia.com
Regards.
Cascardo.
> ---
> drivers/net/wireless/realtek/rtw88/mac80211.c | 7 +++++--
> drivers/net/wireless/realtek/rtw88/main.c | 13 +++++++++++--
> drivers/net/wireless/realtek/rtw88/main.h | 2 +-
> drivers/net/wireless/realtek/rtw88/phy.c | 18 ++++++++++++++++++
> drivers/net/wireless/realtek/rtw88/phy.h | 2 ++
> 5 files changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 766f22d31079..9d97e8dd0c1e 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> @@ -92,8 +92,11 @@ static int rtw_ops_config(struct ieee80211_hw *hw, int radio_idx, u32 changed)
> }
> }
>
> - if (changed & IEEE80211_CONF_CHANGE_CHANNEL)
> - rtw_set_channel(rtwdev);
> + if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
> + ret = rtw_set_channel(rtwdev);
> + if (ret)
> + goto out;
> + }
>
> if ((changed & IEEE80211_CONF_CHANGE_IDLE) &&
> (hw->conf.flags & IEEE80211_CONF_IDLE) &&
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index cd9254370fcc..08aebb3c5a78 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -868,23 +868,30 @@ void rtw_get_channel_params(struct cfg80211_chan_def *chandef,
> chan_params->primary_chan = channel->hw_value;
> }
>
> -void rtw_set_channel(struct rtw_dev *rtwdev)
> +int rtw_set_channel(struct rtw_dev *rtwdev)
> {
> const struct rtw_chip_info *chip = rtwdev->chip;
> struct ieee80211_hw *hw = rtwdev->hw;
> struct rtw_hal *hal = &rtwdev->hal;
> struct rtw_channel_params ch_param;
> u8 center_chan, primary_chan, bandwidth, band;
> + int ch_idx;
>
> rtw_get_channel_params(&hw->conf.chandef, &ch_param);
> if (WARN(ch_param.center_chan == 0, "Invalid channel\n"))
> - return;
> + return -EINVAL;
>
> center_chan = ch_param.center_chan;
> primary_chan = ch_param.primary_chan;
> bandwidth = ch_param.bandwidth;
> band = ch_param.center_chan > 14 ? RTW_BAND_5G : RTW_BAND_2G;
>
> + ch_idx = rtw_band_channel_to_idx(band, center_chan);
> + if (ch_idx < 0) {
> + rtw_warn(rtwdev, "not support band %d ch %d\n", band, center_chan);
> + return -EOPNOTSUPP;
> + }
> +
> rtw_update_channel(rtwdev, center_chan, primary_chan, band, bandwidth);
>
> if (rtwdev->scan_info.op_chan)
> @@ -910,6 +917,8 @@ void rtw_set_channel(struct rtw_dev *rtwdev)
> */
> if (!test_bit(RTW_FLAG_SCANNING, rtwdev->flags))
> rtwdev->need_rfk = true;
> +
> + return 0;
> }
>
> void rtw_chip_prepare_tx(struct rtw_dev *rtwdev)
> diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
> index 9c0b746540b0..a368f1a4a003 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.h
> +++ b/drivers/net/wireless/realtek/rtw88/main.h
> @@ -2241,7 +2241,7 @@ bool ltecoex_reg_write(struct rtw_dev *rtwdev, u16 offset, u32 value);
> void rtw_restore_reg(struct rtw_dev *rtwdev,
> struct rtw_backup_info *bckp, u32 num);
> void rtw_desc_to_mcsrate(u16 rate, u8 *mcs, u8 *nss);
> -void rtw_set_channel(struct rtw_dev *rtwdev);
> +int rtw_set_channel(struct rtw_dev *rtwdev);
> void rtw_chip_prepare_tx(struct rtw_dev *rtwdev);
> void rtw_vif_port_config(struct rtw_dev *rtwdev, struct rtw_vif *rtwvif,
> u32 config);
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> index e2ac5c6fd500..a543eaa57f2c 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.c
> +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> @@ -1630,6 +1630,24 @@ static int rtw_channel_to_idx(u8 band, u8 channel)
> return ch_idx;
> }
>
> +int rtw_band_channel_to_idx(enum rtw_supported_band band, u8 channel)
> +{
> + u8 phy_band;
> +
> + switch (band) {
> + case RTW_BAND_2G:
> + phy_band = PHY_BAND_2G;
> + break;
> + case RTW_BAND_5G:
> + phy_band = PHY_BAND_5G;
> + break;
> + default:
> + return -1;
> + }
> +
> + return rtw_channel_to_idx(phy_band, channel);
> +}
> +
> static void rtw_phy_set_tx_power_limit(struct rtw_dev *rtwdev, u8 regd, u8 band,
> u8 bw, u8 rs, u8 ch, s8 pwr_limit)
> {
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.h b/drivers/net/wireless/realtek/rtw88/phy.h
> index 8449936497bb..98aeb576e24d 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.h
> +++ b/drivers/net/wireless/realtek/rtw88/phy.h
> @@ -201,4 +201,6 @@ enum rtw_phy_cck_pd_lv {
> #define RRSR_RATE_ORDER_MAX 0xfffff
> #define RRSR_RATE_ORDER_CCK_LEN 4
>
> +int rtw_band_channel_to_idx(enum rtw_supported_band band, u8 channel);
> +
> #endif
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Marcus Glocker @ 2026-05-14 17:20 UTC (permalink / raw)
To: Baochen Qiang
Cc: Maxim Storetvedt, ath12k, linux-wireless, jjohnson, kvalo,
Mark Kettenis
In-Reply-To: <0ef41d1f-e9ec-4f90-9f6a-77cb8fa3a7e7@oss.qualcomm.com>
Hi Baochen, all,
On Thu, May 14, 2026 at 09:55:30AM +0800, Baochen Qiang wrote:
> > With that fixed, the firmware error is gone, and we can now receive
> > and IP from DHCP. We're working on getting the TX path work next.
>
> OK, good to see it gets fixed!
Since today we also got RX/TX fixed, so we have now an initial working
ath12k device with our qwz driver on OpenBSD.
What is still missing from the firmware side; The PCI-id of the
WCN7850 chip included in the Samsung Galaxy Book4 Edge isn't included
yet in to the Linux firmware package. I've addressed this a few times,
but unfortunately no feedback. That's the additional PCI-id line
which is required for the Samsung Galaxy Book4 Edge:
--- board-2.json.orig Sun Apr 26 08:06:37 2026
+++ board-2.json Sun Apr 26 08:07:45 2026
@@ -160,7 +160,8 @@
{
"names": [
"bus=pci,vendor=17cb,device=1107,subsystem-vendor=17aa,subsystem-device=e0e6,qmi-chip-id=2,qmi-board-id=255",
- "bus=pci,vendor=17cb,device=1107,subsystem-vendor=1eac,subsystem-device=8003,qmi-chip-id=2,qmi-board-id=255"
+ "bus=pci,vendor=17cb,device=1107,subsystem-vendor=1eac,subsystem-device=8003,qmi-chip-id=2,qmi-board-id=255",
+ "bus=pci,vendor=17cb,device=1107,subsystem-vendor=17cb,subsystem-device=1107,qmi-chip-id=2,qmi-board-id=255"
],
"data": "bus=pci,vendor=17cb,device=1107,subsystem-vendor=17aa,subsystem-device=e0e6,qmi-chip-id=2,qmi-board-id=255.bin"
},
@@ -202,4 +203,4 @@
}
]
}
-]
\ No newline at end of file
+]
With the resulting 'qwz-wcn7850-hw2.0-board-2' firmware board file,
we have now proved that the ath12k driver is working with Linux and
OpenBSD on the Samsung Galaxy Book4 Edge. Maxim Storetvedt did test
with Linux.
Given that, would it be possible to include this PCI-id to the next
linux-firmware package?
Thanks and Regards,
Marcus
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: clear shared SRNG pointer state on restart
From: Jeff Johnson @ 2026-05-14 15:16 UTC (permalink / raw)
To: kfarnung, Jeff Johnson, Muhammad Usama Anjum, Baochen Qiang
Cc: linux-wireless, ath11k, linux-kernel, santiagorr, stable
In-Reply-To: <20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com>
On 5/13/2026 9:52 PM, Kyle Farnung via B4 Relay wrote:
> From: Kyle Farnung <kfarnung@gmail.com>
>
> LMAC rings reuse the shared rdp/wrp pointer buffers without going
> through the normal SRNG hw-init path that zeros non-LMAC ring
> pointers. After restart, ath11k_hal_srng_clear() can therefore hand
> stale hp/tp state from the previous firmware instance back to the new
> one.
>
> Clear the shared pointer buffers while keeping the allocations in
> place so restart still avoids reallocating SRNG DMA memory, but starts
> with fresh ring-pointer state.
>
> Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
I'm going to change this to a Closes: tag in my pending branch
> Signed-off-by: Kyle Farnung <kfarnung@gmail.com>
> ---
> This patch is the result of investigating suspend/resume failures on a
> Lenovo ThinkPad P14s Gen 5 AMD with ath11k.
>
> I originally proposed extending the existing ath11k PM quirk for this
> platform, but after discussion in [1] and bisection the issue appears to
> be a regression introduced by [2]. There is also a parallel report in [3]
> that appears consistent with the same root cause. This patch keeps the
> intended no-reallocation behavior from that change, but clears the
> preserved shared SRNG pointer state so restart begins from a clean state.
>
> Testing so far has been limited to local suspend/resume cycling on the
> affected system. The issue was originally reproduced on v7.0.4, and the
> patch was also built and tested on top of ath-current with repeated
> suspend/resume cycles on a Lenovo ThinkPad P14s Gen 5 AMD.
>
> [1] https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
> [2] 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132343
> ---
> drivers/net/wireless/ath/ath11k/hal.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath11k/hal.c b/drivers/net/wireless/ath/ath11k/hal.c
> index e821e5a62c1c0..0c0aeb803018e 100644
> --- a/drivers/net/wireless/ath/ath11k/hal.c
> +++ b/drivers/net/wireless/ath/ath11k/hal.c
> @@ -1387,14 +1387,21 @@ EXPORT_SYMBOL(ath11k_hal_srng_deinit);
>
> void ath11k_hal_srng_clear(struct ath11k_base *ab)
> {
> - /* No need to memset rdp and wrp memory since each individual
> - * segment would get cleared in ath11k_hal_srng_src_hw_init()
> - * and ath11k_hal_srng_dst_hw_init().
> + /* Preserve the shared pointer buffers, but clear the previous
Since you are touching it I'm going to change this from the obsolete
networking block comment style to the universal block comment style with
/* on a line by itself
> + * firmware instance's hp/tp state before handing them back to FW.
> + * LMAC rings reuse this shared memory without going through the
> + * normal SRNG hw-init path that zeros non-LMAC ring pointers.
> */
> memset(ab->hal.srng_list, 0,
> sizeof(ab->hal.srng_list));
> memset(ab->hal.shadow_reg_addr, 0,
> sizeof(ab->hal.shadow_reg_addr));
> + if (ab->hal.rdp.vaddr)
> + memset(ab->hal.rdp.vaddr, 0,
> + sizeof(*ab->hal.rdp.vaddr) * HAL_SRNG_RING_ID_MAX);
> + if (ab->hal.wrp.vaddr)
> + memset(ab->hal.wrp.vaddr, 0,
> + sizeof(*ab->hal.wrp.vaddr) * HAL_SRNG_NUM_LMAC_RINGS);
> ab->hal.avail_blk_resource = 0;
> ab->hal.current_blk_index = 0;
> ab->hal.num_shadow_reg_configured = 0;
>
> ---
> base-commit: 54a5b38e4396530e5b2f12b54d3844e860ab6784
> change-id: 20260513-kfarnung-ath11k-srng-clear-pointer-state-91d8ab07e5e2
>
> Best regards,
^ permalink raw reply
* Re: [PATCH ath-next v2 0/2] wifi: ath12k: Add support for handling incumbent signal interference in 6 GHz
From: Baochen Qiang @ 2026-05-14 8:48 UTC (permalink / raw)
To: Amith A; +Cc: ath12k, linux-wireless
In-Reply-To: <20260511040242.1351792-1-amith.a@oss.qualcomm.com>
On Mon, 11 May 2026 09:32:40 +0530, Amith A wrote:
> This patch series adds the implementation of handling of interferences
> due to incumbent signals in 6 GHz channels. When an interference is
> detected, the firmware indicates it to the host using the
> WMI_DCS_INTERFERENCE_EVENT.
>
> The driver is expected to parse the new WMI event to retrieve the
> interference information, validate the interference detected channel and
> bitmap, and indicate the interference to mac80211, which then notifies
> this interference to the userspace.
> ---
> Changes in v2:
> - Added an explicit len check in sub-TLV parser before accessing info.
> ---
> Aishwarya R (2):
> wifi: ath12k: Add support for handling incumbent signal interference
> in 6 GHz
> wifi: ath12k: Add debugfs support to simulate incumbent signal
> interference
>
> drivers/net/wireless/ath/ath12k/core.h | 8 +
> drivers/net/wireless/ath/ath12k/debugfs.c | 46 +++
> drivers/net/wireless/ath/ath12k/mac.c | 46 +++
> drivers/net/wireless/ath/ath12k/wmi.c | 425 ++++++++++++++++++++++
> drivers/net/wireless/ath/ath12k/wmi.h | 72 +++-
> 5 files changed, 596 insertions(+), 1 deletion(-)
>
>
> base-commit: e12d2d3983acb150fd987d19ec6a2a530da110df
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Baochen Qiang @ 2026-05-14 8:15 UTC (permalink / raw)
To: Rameshkumar Sundaram, Jose Ignacio Tornos Martinez
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <95bff017-3554-425f-ad8e-767f9cbe1277@oss.qualcomm.com>
On 5/14/2026 2:55 PM, Rameshkumar Sundaram wrote:
> On 5/14/2026 11:48 AM, Jose Ignacio Tornos Martinez wrote:
>> Hello Rameshkumar,
>>
>>> I agree that setting tx_status to NULL makes ath11k_dp_free() more
>>> defensive, and it matches the ath12k fix.
>> Ok, I agree too.
>>
>>> However, i am still wondering how the second ath11k_dp_free() is reached
>>> if ATH11K_FLAG_QMI_FAIL is set.
>>>
>>> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
>>> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>>>
>>> ath11k_pci_remove()
>>> ath11k_core_deinit()
>>> ath11k_core_soc_destroy()
>>> ath11k_dp_free()
>>>
>>> should not run.
>>>
>>> So if the double free is still reproducible with QMI_FAIL set (with the
>>> change i proposed), either the flag is not actually set in this failure
>>> case, or there is another path calling ath11k_dp_free() ?
>> Let me try to clarify the issue more.
>> There are two error actions:
>> - First the previous error. I reproduce the situation as I commented: running
>> in a VM the default upstream kernel (with this card using PCI passthrough),
>> since this is always failing. Let me show the logs in this situation:
>> [ 15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
>> [ 15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
>> [ 15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
>> [ 16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id
>> 0x400c0200
>> [ 16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp
>> 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
>> [ 18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion,
>> polling..
>> [ 19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
>> [ 19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
>> [ 19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
>> [ 19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
>> [ 19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
>> [ 29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
>> [ 29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
>> - Second after this, I commanded the unbinded (ath11_pci) and I get the
>> warning. Let extend here the stack trace:
>> [ 24.238198] ? free_large_kmalloc+0x57/0x90
>> [ 24.238199] ? report_bug+0x16b/0x180
>> [ 24.238210] ? handle_bug+0x3c/0x70
>> [ 24.238218] ? exc_invalid_op+0x14/0x70
>> [ 24.238218] ? asm_exc_invalid_op+0x16/0x20
>> [ 24.238224] ? free_large_kmalloc+0x57/0x90
>> [ 24.238227] ath11k_dp_free+0x99/0xb0 [ath11k]
>> [ 24.238275] ath11k_core_deinit+0x12b/0x1a0 [ath11k]
>> [ 24.238287] ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
>> [ 24.238294] pci_device_remove+0x3e/0xb0
>> [ 24.238304] device_release_driver_internal+0x193/0x200
>> [ 24.238315] unbind_store+0x9d/0xb0
>> [ 24.238320] kernfs_fop_write_iter+0x13a/0x1d0
>> [ 24.238330] vfs_write+0x32e/0x470
>> [ 24.238335] ksys_write+0x5f/0xe0
>> [ 24.238336] do_syscall_64+0x5f/0xe0
>> Very easy to reproduce.
>>
>
>
> Thanks much for the logs, that makes sense. The timestamps explain why my earlier
> reasoning did not match the trace: unbind reaches ath11k_pci_remove() before
> ATH11K_FLAG_QMI_FAIL is set by the QMI event worker as it is held up on wlan mode off qmi
how could QMI worker set this flag? the first failure happens in
ath12k_core_qmi_firmware_ready() and upon this failure the QMI worker just break out
without setting any flag, no?
> transaction, so remove still takes the normal ath11k_core_deinit() path.
>
>
> --
> Ramesh
>
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: clear shared SRNG pointer state on restart
From: Baochen Qiang @ 2026-05-14 7:59 UTC (permalink / raw)
To: kfarnung, Jeff Johnson, Muhammad Usama Anjum
Cc: Jeff Johnson, linux-wireless, ath11k, linux-kernel, santiagorr,
stable
In-Reply-To: <20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com>
On 5/14/2026 12:52 PM, Kyle Farnung via B4 Relay wrote:
> From: Kyle Farnung <kfarnung@gmail.com>
>
> LMAC rings reuse the shared rdp/wrp pointer buffers without going
> through the normal SRNG hw-init path that zeros non-LMAC ring
> pointers. After restart, ath11k_hal_srng_clear() can therefore hand
> stale hp/tp state from the previous firmware instance back to the new
> one.
>
> Clear the shared pointer buffers while keeping the allocations in
> place so restart still avoids reallocating SRNG DMA memory, but starts
> with fresh ring-pointer state.
>
> Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
> Signed-off-by: Kyle Farnung <kfarnung@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH RFC wireless-next] wifi: mac80211_hwsim: dont perform rate validation for S1G
From: Lachlan Hodges @ 2026-05-14 7:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, arien.judge
In-Reply-To: <ccef9238eaced219bf7526a30e8ee0acb54ea282.camel@sipsolutions.net>
Hi Johannes,
I am revisiting this thread again with some fresh eyes;
> > It seems that introducing a flags parameter into the ieee80211_link_sta where
> > drivers can apply the inverse i.e LINK_STA_NO_RATE_CONTROL or something similar
> > that before drv_link_sta_rc_update() is called the flag can be tested, something
> > like, for example within rate_control_rate_update():
> >
> > [...]
> > if (sta->uploaded && !(link_sta->pub->flags & LINK_STA_NO_RC))
> > drv_link_sta_rc_update(local, sta->sdata, link_sta->pub,
> > changed);
> > [...]
> >
> > Then w.r.t setting the flag, we could introduce a new function that gets
> > called within mac80211_hwsim_sta_add() called mac80211_hwsim_link_sta_set_flags()
> > or something where it could enumerate the links of the ieee80211_sta and
> > apply the flag to the link with an S1G band channel context?
> >
> > The reason for it being driver-facing is that any future upstream S1G drivers
> > may make use of the .sta_rc_update() callback.
>
> But the .sta_rc_update() call is desired/needed either way (if
> implemented) - the issue is about the _other_ side of this, "if (ref &&
> ref->ops->rate_update)", no?
The actual call into .sta_rc_update() isn't the issue here from mac80211,
but rather the call from mac80211_hwsim_sta_add(). Just for a refresher
on this main idea of this thread - is that during the hwsim tests that
I've made for hostapd the WARN is hit in mac80211_hwsim_sta_rc_update()
since there is no understanding of S1G widths.
But actually looking at this again, even during normal S1G operation
at the current point .sta_rc_update() is never called since there's no
channel switching support and only identical chanctxs are allowed.
In the future you are right we would like this to be supported, but
that is a fair chunk of work down the road ^.^.
Anyways a potentially nicer solution is to only call sta_rc_update()
for non-S1G chanctxs. Something like this:
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim_main.c b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
index 3a0c4366dfdb..a0e81282d42a 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim_main.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
@@ -2788,9 +2788,21 @@ static int mac80211_hwsim_sta_add(struct ieee80211_hw *hw,
struct ieee80211_sta *sta)
{
struct hwsim_sta_priv *sp = (void *)sta->drv_priv;
+ struct ieee80211_chanctx_conf *conf;
hwsim_check_magic(vif);
hwsim_set_sta_magic(sta);
+
+ /*
+ * Don't perform the RC update for S1G chandefs. Since S1G cannot
+ * exist during MLO operation we can take the vif->bss_conf chandef.
+ */
+ scoped_guard(rcu) {
+ conf = rcu_dereference(vif->bss_conf.chanctx_conf);
+ if (conf && cfg80211_chandef_is_s1g(&conf->def))
+ return 0;
+ }
+
mac80211_hwsim_sta_rc_update(hw, vif, &sta->deflink, 0);
if (sta->valid_links) {
I do agree that this is still somewhat hacky, but I think it's a bit
clearer now maybe? I'm not sure. This sort of allows us to get some
basic hwsim infra up and running without introducing a new flag for
S1G rate control and such. I've run the hwsim tests and it seems to
not break any of the MLO tests but I am not an expert there so yea.
Let me know your thoughts, can always explore some other options.
lachlan
^ permalink raw reply related
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Rameshkumar Sundaram @ 2026-05-14 6:56 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, jjohnson
Cc: linux-wireless, ath11k, linux-kernel, stable
In-Reply-To: <20260420110130.509670-1-jtornosm@redhat.com>
On 4/20/2026 4:31 PM, Jose Ignacio Tornos Martinez wrote:
> If there is an error during some initialization related to firmware,
> the buffers dp->tx_ring[i].tx_status are released.
> However this is released again when the device is unbinded (ath11k_pci),
> and we get:
> WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
> Call Trace:
> free_large_kmalloc
> ath11k_dp_free
> ath11k_core_deinit
> ath11k_pci_remove
> ...
>
> The issue is always reproducible from a VM because the MSI addressing
> initialization is failing.
>
> In order to fix the issue, just set the buffers to NULL after releasing in
> order to avoid the double free.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Rameshkumar Sundaram @ 2026-05-14 6:55 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260514061841.9517-1-jtornosm@redhat.com>
On 5/14/2026 11:48 AM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
>
>> I agree that setting tx_status to NULL makes ath11k_dp_free() more
>> defensive, and it matches the ath12k fix.
> Ok, I agree too.
>
>> However, i am still wondering how the second ath11k_dp_free() is reached
>> if ATH11K_FLAG_QMI_FAIL is set.
>>
>> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
>> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>>
>> ath11k_pci_remove()
>> ath11k_core_deinit()
>> ath11k_core_soc_destroy()
>> ath11k_dp_free()
>>
>> should not run.
>>
>> So if the double free is still reproducible with QMI_FAIL set (with the
>> change i proposed), either the flag is not actually set in this failure
>> case, or there is another path calling ath11k_dp_free() ?
> Let me try to clarify the issue more.
> There are two error actions:
> - First the previous error. I reproduce the situation as I commented: running
> in a VM the default upstream kernel (with this card using PCI passthrough),
> since this is always failing. Let me show the logs in this situation:
> [ 15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
> [ 15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
> [ 15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
> [ 16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0200
> [ 16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> [ 18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion, polling..
> [ 19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
> [ 19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
> [ 19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
> [ 19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
> [ 19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
> [ 29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
> [ 29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
> - Second after this, I commanded the unbinded (ath11_pci) and I get the
> warning. Let extend here the stack trace:
> [ 24.238198] ? free_large_kmalloc+0x57/0x90
> [ 24.238199] ? report_bug+0x16b/0x180
> [ 24.238210] ? handle_bug+0x3c/0x70
> [ 24.238218] ? exc_invalid_op+0x14/0x70
> [ 24.238218] ? asm_exc_invalid_op+0x16/0x20
> [ 24.238224] ? free_large_kmalloc+0x57/0x90
> [ 24.238227] ath11k_dp_free+0x99/0xb0 [ath11k]
> [ 24.238275] ath11k_core_deinit+0x12b/0x1a0 [ath11k]
> [ 24.238287] ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
> [ 24.238294] pci_device_remove+0x3e/0xb0
> [ 24.238304] device_release_driver_internal+0x193/0x200
> [ 24.238315] unbind_store+0x9d/0xb0
> [ 24.238320] kernfs_fop_write_iter+0x13a/0x1d0
> [ 24.238330] vfs_write+0x32e/0x470
> [ 24.238335] ksys_write+0x5f/0xe0
> [ 24.238336] do_syscall_64+0x5f/0xe0
> Very easy to reproduce.
>
Thanks much for the logs, that makes sense. The timestamps explain why
my earlier reasoning did not match the trace: unbind reaches
ath11k_pci_remove() before ATH11K_FLAG_QMI_FAIL is set by the QMI event
worker as it is held up on wlan mode off qmi transaction, so remove
still takes the normal ath11k_core_deinit() path.
--
Ramesh
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Jose Ignacio Tornos Martinez @ 2026-05-14 6:18 UTC (permalink / raw)
To: jtornosm
Cc: ath11k, jjohnson, linux-kernel, linux-wireless,
rameshkumar.sundaram, stable
In-Reply-To: <20260507070808.367442-1-jtornosm@redhat.com>
Hello Rameshkumar,
> I agree that setting tx_status to NULL makes ath11k_dp_free() more
> defensive, and it matches the ath12k fix.
Ok, I agree too.
> However, i am still wondering how the second ath11k_dp_free() is reached
> if ATH11K_FLAG_QMI_FAIL is set.
>
> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>
> ath11k_pci_remove()
> ath11k_core_deinit()
> ath11k_core_soc_destroy()
> ath11k_dp_free()
>
> should not run.
>
> So if the double free is still reproducible with QMI_FAIL set (with the
> change i proposed), either the flag is not actually set in this failure
> case, or there is another path calling ath11k_dp_free() ?
Let me try to clarify the issue more.
There are two error actions:
- First the previous error. I reproduce the situation as I commented: running
in a VM the default upstream kernel (with this card using PCI passthrough),
since this is always failing. Let me show the logs in this situation:
[ 15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
[ 15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
[ 15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
[ 16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0200
[ 16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[ 18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion, polling..
[ 19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
[ 19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
[ 19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
[ 19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
[ 19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
[ 29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
[ 29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
- Second after this, I commanded the unbinded (ath11_pci) and I get the
warning. Let extend here the stack trace:
[ 24.238198] ? free_large_kmalloc+0x57/0x90
[ 24.238199] ? report_bug+0x16b/0x180
[ 24.238210] ? handle_bug+0x3c/0x70
[ 24.238218] ? exc_invalid_op+0x14/0x70
[ 24.238218] ? asm_exc_invalid_op+0x16/0x20
[ 24.238224] ? free_large_kmalloc+0x57/0x90
[ 24.238227] ath11k_dp_free+0x99/0xb0 [ath11k]
[ 24.238275] ath11k_core_deinit+0x12b/0x1a0 [ath11k]
[ 24.238287] ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
[ 24.238294] pci_device_remove+0x3e/0xb0
[ 24.238304] device_release_driver_internal+0x193/0x200
[ 24.238315] unbind_store+0x9d/0xb0
[ 24.238320] kernfs_fop_write_iter+0x13a/0x1d0
[ 24.238330] vfs_write+0x32e/0x470
[ 24.238335] ksys_write+0x5f/0xe0
[ 24.238336] do_syscall_64+0x5f/0xe0
Very easy to reproduce.
Anyway, although you can avoid a specific path, IMHO this small fix is
recommendable to avoid other similar situations.
Thanks
Best regards
José Ignacio
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
From: Rameshkumar Sundaram @ 2026-05-14 5:13 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260514-ath12k-fix-20mhz-only-mcs-map-v1-1-a38d4a9b21a2@oss.qualcomm.com>
On 5/14/2026 9:02 AM, Baochen Qiang wrote:
> When connecting to an AP configured for EHT 20 MHz with a full EHT
> MCS/NSS map (supporting MCS 0-13)
>
> Supported EHT-MCS and NSS Set
> EHT-MCS Map (BW <= 80MHz): 0x444444
> .... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
> .... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
> .... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
> .... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
> .... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
> 0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4
>
> TX throughput is observed to be significantly lower than expected.
> Investigation shows that TX rates are limited to EHT MCS 11, even though
> the AP advertises support for EHT MCS 12/13.
>
> The root cause is an incorrect parsing of the Supported EHT-MCS and NSS
> Set element in ath12k_peer_assoc_h_eht().
>
> IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20
> MHz-Only Non-AP STAs.
>
> IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all
> other AP and non-AP STAs.
>
> Currently the first format is parsed when the peer advertises no wider
> HE channel width support, without considering whether it is an AP or a
> non-AP STA. This is incorrect: the peer AP's capabilities must be parsed
> using Figure 9-1074at even when it operates on 20 MHz only. Parsing it
> as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero,
> which is then passed to firmware, leading firmware to assume the peer
> does not support MCS 13 and to limit TX rates at MCS 11.
>
> Fix this by parsing the Figure 9-1074as format only when the peer is a
> 20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or
> mesh point.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Fixes: 6c95151e2e77 ("wifi: ath12k: Add EHT MCS/NSS rates to Peer Assoc")
> Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
From: Kyle Farnung @ 2026-05-14 5:01 UTC (permalink / raw)
To: Santiago Ruano Rincón
Cc: Jeff Johnson, Jeff Johnson, linux-wireless, ath11k, linux-kernel,
kfarnung, Mark Pearson, koike
In-Reply-To: <agS7fr8mDI9TLpvh@voleno>
On Wed, May 13, 2026 at 10:57 AM Santiago Ruano Rincón
<santiagorr@riseup.net> wrote:
>
> El 12/05/26 a las 20:30, Kyle Farnung escribió:
> > On Tue, May 12, 2026 at 5:03 PM Jeff Johnson
> > <jeff.johnson@oss.qualcomm.com> wrote:
> > >
> > > On 5/6/2026 12:54 PM, Santiago Ruano Rincón wrote:
> > > > Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
> > > > table") added some Lenovo platform IDs to the quirk table to address a
> > > > wakeup from suspend issue [1]. However, at least P14s Gen 5 AMD, as
> > > > reported by Kyle Farnung [2], and P14s Gen 3 AMD are missing in the
> > > > table. This commit adds the two corresponding Lenovo version IDs for
> > > > each.
> > > >
> > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> > > > [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
> > > >
> > > > Tested-on: P14s G3 AMD running 7.0.3.
> > > >
> > > > Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
> > > > Co-authored-by: Kyle Farnung <kfarnung@gmail.com>
> > >
> > > This is not a standard Linux kernel commit tag.
> > > Co-developed-by: could be used, but I'd need a Signed-off-by: from Kyle
> > >
> > > Kyle, if you'd like these added please reply with both a Co-developed-by and
> > > a Signed-off-by tag
> >
> > I re-tested the bug behavior on the v7.0.4 tag and found that I'm not able
> > to reproduce it on my device. I put the device to sleep and then unplugged
> > and replugged power; it never woke up until I intentionally woke it.
> >
> > Based on discussion in [3], I narrowed my issue with wi-fi disassociation
> > on wake to a suspect commit [4]. I'm developing a patch that clears the rdp
> > and wrp buffers during wake to clear out any stale state in the LMAC rings.
> > I'll submit that once I'm done testing it.
> >
> > Santiago: Are you seeing the sleep/wake bug from [1] or something similar
> > to what I was seeing around disconnections on wake?
>
> I was seeing wifi issues after wake-up, including disassociations, as
> described at https://bugs.debian.org/1132343.
Thanks for the confirmation. I went ahead and submitted a patch for the
suspected SRNG restart issue in [5].
For my P14s Gen 5 AMD, I don't think the PM quirk is the right fix at
this point, so please don't include the 21ME/21MF IDs on my account for
now. This new patch seems like a better match for the disassociation
issue I was seeing after resume.
Please try it out if you have a chance. I've done around 12 sleep/wake
cycles so far without issue.
[5] https://lore.kernel.org/all/20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com/
>
> >
> > [3] https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
> > [4] 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and
> > re-initialize again")
> >
> > >
> > > I can apply these fixes when I process the patch in my tree.
> > >
> > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> > >
> > > > Signed-off-by: Santiago Ruano Rincón <santiagorr@riseup.net>
> > > > ---
> > > > Changes in v2:
> > > > - Merged the Lenovo P14s G5 AMD #1 and #2 related changes proposed by
> > > > Kyle Farnung in
> > > > https://lore.kernel.org/all/20260330-p14s-pm-quirk-v2-1-ef18ce07996b@gmail.com/
> > > > - Added Kyle Farnung as Co-author of the commit
> > > > - Added the second ID of Lenovo P14s G3 AMD, and adapt the comments
> > > > accordingly
> > > > - v1: https://lore.kernel.org/ath11k/20260423211458.458911-1-santiagorr@riseup.net/
> > > > ---
> > > > drivers/net/wireless/ath/ath11k/core.c | 28 ++++++++++++++++++++++++++
> > > > 1 file changed, 28 insertions(+)
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> > > > index 3f6f4db5b7ee..c1ce0a11af44 100644
> > > > --- a/drivers/net/wireless/ath/ath11k/core.c
> > > > +++ b/drivers/net/wireless/ath/ath11k/core.c
> > > > @@ -957,6 +957,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
> > > > DMI_MATCH(DMI_PRODUCT_NAME, "21K4"),
> > > > },
> > > > },
> > > > + {
> > > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > > + .matches = { /* P14s G3 AMD #1 */
> > > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > > + DMI_MATCH(DMI_PRODUCT_NAME, "21J5"),
> > > > + },
> > > > + },
> > > > + {
> > > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > > + .matches = { /* P14s G3 AMD #2 */
> > > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > > + DMI_MATCH(DMI_PRODUCT_NAME, "21J6"),
> > > > + },
> > > > + },
> > > > {
> > > > .driver_data = (void *)ATH11K_PM_WOW,
> > > > .matches = { /* P14s G4 AMD #1 */
> > > > @@ -971,6 +985,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
> > > > DMI_MATCH(DMI_PRODUCT_NAME, "21K6"),
> > > > },
> > > > },
> > > > + {
> > > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > > + .matches = { /* P14s G5 AMD #1 */
> > > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > > + DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
> > > > + },
> > > > + },
> > > > + {
> > > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > > + .matches = { /* P14s G5 AMD #2 */
> > > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > > + DMI_MATCH(DMI_PRODUCT_NAME, "21MF"),
> > > > + },
> > > > + },
> > > > {
> > > > .driver_data = (void *)ATH11K_PM_WOW,
> > > > .matches = { /* T16 G2 AMD #1 */
> > >
^ permalink raw reply
* Re: [PATCH ath-next v2 0/2] wifi: ath12k: Add support for handling incumbent signal interference in 6 GHz
From: Rameshkumar Sundaram @ 2026-05-14 5:01 UTC (permalink / raw)
To: Amith A, ath12k; +Cc: linux-wireless
In-Reply-To: <20260511040242.1351792-1-amith.a@oss.qualcomm.com>
On 5/11/2026 9:32 AM, Amith A wrote:
> This patch series adds the implementation of handling of interferences
> due to incumbent signals in 6 GHz channels. When an interference is
> detected, the firmware indicates it to the host using the
> WMI_DCS_INTERFERENCE_EVENT.
>
> The driver is expected to parse the new WMI event to retrieve the
> interference information, validate the interference detected channel and
> bitmap, and indicate the interference to mac80211, which then notifies
> this interference to the userspace.
> ---
> Changes in v2:
> - Added an explicit len check in sub-TLV parser before accessing info.
> ---
> Aishwarya R (2):
> wifi: ath12k: Add support for handling incumbent signal interference
> in 6 GHz
> wifi: ath12k: Add debugfs support to simulate incumbent signal
> interference
>
> drivers/net/wireless/ath/ath12k/core.h | 8 +
> drivers/net/wireless/ath/ath12k/debugfs.c | 46 +++
> drivers/net/wireless/ath/ath12k/mac.c | 46 +++
> drivers/net/wireless/ath/ath12k/wmi.c | 425 ++++++++++++++++++++++
> drivers/net/wireless/ath/ath12k/wmi.h | 72 +++-
> 5 files changed, 596 insertions(+), 1 deletion(-)
>
>
> base-commit: e12d2d3983acb150fd987d19ec6a2a530da110df
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Rameshkumar Sundaram @ 2026-05-14 4:54 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, rameshkumar.sundaram
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260508103202.456865-1-jtornosm@redhat.com>
On 5/8/2026 4:01 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
>
>> What is the exact failure? Do you see any driver error logs when it occurs?
> No error log, just the warning.
>
>> Got it. I was just thinking along with the proposed fix — whether we
>> might also need to handle the sequencing on QMI failure.
>> In other words, do you think the issue(double free) would still be
>> reproducible if we include a change like below ?
> Yes, I think so and in addition the code is more robust.
>
I agree that setting tx_status to NULL makes ath11k_dp_free() more
defensive, and it matches the ath12k fix.
However, i am still wondering how the second ath11k_dp_free() is reached
if ATH11K_FLAG_QMI_FAIL is set.
In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
ath11k_pci_remove()
ath11k_core_deinit()
ath11k_core_soc_destroy()
ath11k_dp_free()
should not run.
So if the double free is still reproducible with QMI_FAIL set (with the
change i proposed), either the flag is not actually set in this failure
case, or there is another path calling ath11k_dp_free() ?
--
Ramesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox