* [PATCH iwlwifi-next 06/15] wifi: iwlwifi: Transition to basic uAPSD with MAC_PM_POWER_TABLE API VER_3
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Avinash Bhatt
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Avinash Bhatt <avinash.bhatt@intel.com>
uAPSD is transitioning to a certification-only feature. The new
firmware API version 3 removes advanced uAPSD fields, keeping only
basic parameters needed for certification testing.
Support the new VER_3 API in the MLD driver while maintaining
backward compatibility with VER_1/2. The MVM driver continues
using VER_2 only. Remove the obsolete PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION
notification from the MLD driver
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
.../net/wireless/intel/iwlwifi/fw/api/power.h | 48 ++++-
.../net/wireless/intel/iwlwifi/mld/iface.c | 18 --
.../net/wireless/intel/iwlwifi/mld/iface.h | 3 -
drivers/net/wireless/intel/iwlwifi/mld/mld.c | 1 -
.../net/wireless/intel/iwlwifi/mld/notif.c | 6 -
.../net/wireless/intel/iwlwifi/mld/power.c | 177 ++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +-
.../net/wireless/intel/iwlwifi/mvm/power.c | 14 +-
8 files changed, 214 insertions(+), 57 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
index a3f916630df2..115e65ba19f8 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/api/power.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
/*
- * Copyright (C) 2012-2014, 2018-2025 Intel Corporation
+ * Copyright (C) 2012-2014, 2018-2026 Intel Corporation
* Copyright (C) 2013-2014 Intel Mobile Communications GmbH
* Copyright (C) 2015-2017 Intel Deutschland GmbH
*/
@@ -85,12 +85,13 @@ struct iwl_ltr_config_cmd {
* '1' PM could sleep over DTIM till listen Interval.
* @POWER_FLAGS_SNOOZE_ENA_MSK: Enable snoozing only if uAPSD is enabled and all
* access categories are both delivery and trigger enabled.
+ * (Not supported since version 3)
* @POWER_FLAGS_BT_SCO_ENA: Enable BT SCO coex only if uAPSD and
* PBW Snoozing enabled
* @POWER_FLAGS_ADVANCE_PM_ENA_MSK: Advanced PM (uAPSD) enable mask
* @POWER_FLAGS_LPRX_ENA_MSK: Low Power RX enable.
* @POWER_FLAGS_UAPSD_MISBEHAVING_ENA_MSK: AP/GO's uAPSD misbehaving
- * detection enablement
+ * detection enablement (Not supported since version 3)
* @POWER_FLAGS_ENABLE_SMPS_MSK: SMPS is allowed for this vif
*/
enum iwl_power_flags {
@@ -175,9 +176,9 @@ struct iwl_device_power_cmd {
} __packed;
/**
- * struct iwl_mac_power_cmd - New power command containing uAPSD support
+ * struct iwl_mac_power_cmd_v2 - power command V2 containing uAPSD support
* MAC_PM_POWER_TABLE = 0xA9 (command, has simple generic response)
- * @id_and_color: MAC contex identifier, &enum iwl_ctxt_id_and_color
+ * @id_and_color: MAC context identifier, &enum iwl_ctxt_id_and_color
* @flags: Power table command flags from POWER_FLAGS_*
* @keep_alive_seconds: Keep alive period in seconds. Default - 25 sec.
* Minimum allowed:- 3 * DTIM. Keep alive period must be
@@ -216,7 +217,7 @@ struct iwl_device_power_cmd {
* @limited_ps_threshold: (unused)
* @reserved: reserved (padding)
*/
-struct iwl_mac_power_cmd {
+struct iwl_mac_power_cmd_v2 {
/* CONTEXT_DESC_API_T_VER_1 */
__le32 id_and_color;
@@ -242,6 +243,43 @@ struct iwl_mac_power_cmd {
u8 reserved;
} __packed; /* CLIENT_PM_POWER_TABLE_S_VER_1, VER_2 */
+/**
+ * struct iwl_mac_power_cmd - power command
+ * MAC_PM_POWER_TABLE = 0xA9 (command, has simple generic response)
+ * @id_and_color: MAC context identifier, &enum iwl_ctxt_id_and_color
+ * @flags: Power table command flags from POWER_FLAGS_*
+ * @keep_alive_seconds: Keep alive period in seconds. Default - 25 sec.
+ * Minimum allowed:- 3 * DTIM. Keep alive period must be
+ * set regardless of power scheme or current power state.
+ * FW use this value also when PM is disabled.
+ * @rx_data_timeout: Minimum time (usec) from last Rx packet for AM to
+ * PSM transition - legacy PM
+ * @tx_data_timeout: Minimum time (usec) from last Tx packet for AM to
+ * PSM transition - legacy PM
+ * @lprx_rssi_threshold: Signal strength up to which LP RX can be enabled.
+ * Default: 80dbm
+ * @skip_dtim_periods: Number of DTIM periods to skip if Skip over DTIM flag
+ * is set. For example, if it is required to skip over
+ * one DTIM, this value need to be set to 2 (DTIM periods).
+ * @qndp_tid: TID client shall use for uAPSD QNDP triggers
+ * @uapsd_ac_flags: Set trigger-enabled and delivery-enabled indication for
+ * each corresponding AC.
+ * Use IEEE80211_WMM_IE_STA_QOSINFO_AC* for correct values.
+ */
+struct iwl_mac_power_cmd {
+ /* CONTEXT_DESC_API_T_VER_1 */
+ __le32 id_and_color;
+
+ __le16 flags;
+ __le16 keep_alive_seconds;
+ __le32 rx_data_timeout;
+ __le32 tx_data_timeout;
+ u8 lprx_rssi_threshold;
+ u8 skip_dtim_periods;
+ u8 qndp_tid;
+ u8 uapsd_ac_flags;
+} __packed; /* CLIENT_PM_POWER_TABLE_S_VER_3 */
+
/*
* struct iwl_uapsd_misbehaving_ap_notif - FW sends this notification when
* associated AP is identified as improperly implementing uAPSD protocol.
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/iface.c b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
index 5fc3f6729455..4fe57d79daa6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/iface.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
@@ -739,24 +739,6 @@ void iwl_mld_handle_probe_resp_data_notif(struct iwl_mld *mld,
kfree_rcu(old_data, rcu_head);
}
-void iwl_mld_handle_uapsd_misbehaving_ap_notif(struct iwl_mld *mld,
- struct iwl_rx_packet *pkt)
-{
- struct iwl_uapsd_misbehaving_ap_notif *notif = (void *)pkt->data;
- struct ieee80211_vif *vif;
-
- if (IWL_FW_CHECK(mld, notif->mac_id >= ARRAY_SIZE(mld->fw_id_to_vif),
- "mac id is invalid: %d\n", notif->mac_id))
- return;
-
- vif = wiphy_dereference(mld->wiphy, mld->fw_id_to_vif[notif->mac_id]);
-
- if (WARN_ON(!vif) || ieee80211_vif_is_mld(vif))
- return;
-
- IWL_WARN(mld, "uapsd misbehaving AP: %pM\n", vif->bss_conf.bssid);
-}
-
void iwl_mld_handle_datapath_monitor_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt)
{
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/iface.h b/drivers/net/wireless/intel/iwlwifi/mld/iface.h
index 71c794204475..d6fb58e785e5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/iface.h
+++ b/drivers/net/wireless/intel/iwlwifi/mld/iface.h
@@ -274,9 +274,6 @@ void iwl_mld_handle_probe_resp_data_notif(struct iwl_mld *mld,
void iwl_mld_handle_datapath_monitor_notif(struct iwl_mld *mld,
struct iwl_rx_packet *pkt);
-void iwl_mld_handle_uapsd_misbehaving_ap_notif(struct iwl_mld *mld,
- struct iwl_rx_packet *pkt);
-
void iwl_mld_reset_cca_40mhz_workaround(struct iwl_mld *mld,
struct ieee80211_vif *vif);
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mld.c b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
index 9a3b768fce7a..25bab6ab6375 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mld.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mld.c
@@ -162,7 +162,6 @@ static const struct iwl_hcmd_names iwl_mld_legacy_names[] = {
HCMD_NAME(PHY_CONFIGURATION_CMD),
HCMD_NAME(SCAN_OFFLOAD_UPDATE_PROFILES_CMD),
HCMD_NAME(POWER_TABLE_CMD),
- HCMD_NAME(PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION),
HCMD_NAME(BEACON_NOTIFICATION),
HCMD_NAME(BEACON_TEMPLATE_CMD),
HCMD_NAME(TX_ANT_CONFIGURATION_CMD),
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/notif.c b/drivers/net/wireless/intel/iwlwifi/mld/notif.c
index 4e9f3768c381..1c81152042ab 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/notif.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/notif.c
@@ -339,8 +339,6 @@ CMD_VERSIONS(emlsr_mode_notif,
CMD_VER_ENTRY(2, iwl_esr_mode_notif))
CMD_VERSIONS(emlsr_trans_fail_notif,
CMD_VER_ENTRY(1, iwl_esr_trans_fail_notif))
-CMD_VERSIONS(uapsd_misbehaving_ap_notif,
- CMD_VER_ENTRY(1, iwl_uapsd_misbehaving_ap_notif))
CMD_VERSIONS(time_msmt_notif,
CMD_VER_ENTRY(1, iwl_time_msmt_notify))
CMD_VERSIONS(time_sync_confirm_notif,
@@ -363,8 +361,6 @@ DEFINE_SIMPLE_CANCELLATION(scan_complete, iwl_umac_scan_complete, uid)
DEFINE_SIMPLE_CANCELLATION(scan_start, iwl_umac_scan_start, uid)
DEFINE_SIMPLE_CANCELLATION(probe_resp_data, iwl_probe_resp_data_notif,
mac_id)
-DEFINE_SIMPLE_CANCELLATION(uapsd_misbehaving_ap, iwl_uapsd_misbehaving_ap_notif,
- mac_id)
DEFINE_SIMPLE_CANCELLATION(ftm_resp, iwl_tof_range_rsp_ntfy, request_id)
DEFINE_SIMPLE_CANCELLATION(beacon_filter, iwl_beacon_filter_notif, link_id)
@@ -455,8 +451,6 @@ const struct iwl_rx_handler iwl_mld_rx_handlers[] = {
emlsr_mode_notif, RX_HANDLER_ASYNC)
RX_HANDLER_NO_OBJECT(MAC_CONF_GROUP, EMLSR_TRANS_FAIL_NOTIF,
emlsr_trans_fail_notif, RX_HANDLER_ASYNC)
- RX_HANDLER_OF_VIF(LEGACY_GROUP, PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION,
- uapsd_misbehaving_ap_notif)
RX_HANDLER_NO_OBJECT(LEGACY_GROUP,
WNM_80211V_TIMING_MEASUREMENT_NOTIFICATION,
time_msmt_notif, RX_HANDLER_SYNC)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/power.c b/drivers/net/wireless/intel/iwlwifi/mld/power.c
index fe71da8b9c89..da065a446f81 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/power.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/power.c
@@ -88,10 +88,10 @@ static bool iwl_mld_power_is_radar(struct iwl_mld *mld,
return chanctx_conf->def.chan->flags & IEEE80211_CHAN_RADAR;
}
-static void iwl_mld_power_configure_uapsd(struct iwl_mld *mld,
- struct iwl_mld_link *link,
- struct iwl_mac_power_cmd *cmd,
- bool ps_poll)
+static void iwl_mld_power_configure_uapsd_v2(struct iwl_mld *mld,
+ struct iwl_mld_link *link,
+ struct iwl_mac_power_cmd_v2 *cmd,
+ bool ps_poll)
{
bool tid_found = false;
@@ -150,10 +150,54 @@ static void iwl_mld_power_configure_uapsd(struct iwl_mld *mld,
cmd->uapsd_max_sp = mld->hw->uapsd_max_sp_len;
}
+static void iwl_mld_power_configure_uapsd(struct iwl_mld *mld,
+ struct iwl_mld_link *link,
+ struct iwl_mac_power_cmd *cmd,
+ bool ps_poll)
+{
+ bool tid_found = false;
+
+ /* set advanced pm flag with no uapsd ACs to enable ps-poll */
+ if (ps_poll) {
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
+ return;
+ }
+
+ for (enum ieee80211_ac_numbers ac = IEEE80211_AC_VO;
+ ac <= IEEE80211_AC_BK;
+ ac++) {
+ if (!link->queue_params[ac].uapsd)
+ continue;
+
+ cmd->flags |=
+ cpu_to_le16(POWER_FLAGS_ADVANCE_PM_ENA_MSK);
+ cmd->uapsd_ac_flags |= BIT(ac);
+
+ /* QNDP TID - the highest TID with no admission control */
+ if (!tid_found && !link->queue_params[ac].acm) {
+ tid_found = true;
+ switch (ac) {
+ case IEEE80211_AC_VO:
+ cmd->qndp_tid = 6;
+ break;
+ case IEEE80211_AC_VI:
+ cmd->qndp_tid = 5;
+ break;
+ case IEEE80211_AC_BE:
+ cmd->qndp_tid = 0;
+ break;
+ case IEEE80211_AC_BK:
+ cmd->qndp_tid = 1;
+ break;
+ }
+ }
+ }
+}
+
static void
iwl_mld_power_config_skip_dtim(struct iwl_mld *mld,
const struct ieee80211_bss_conf *link_conf,
- struct iwl_mac_power_cmd *cmd)
+ u8 *skip_dtim_periods, __le16 *flags)
{
unsigned int dtimper_tu;
unsigned int dtimper;
@@ -171,15 +215,15 @@ iwl_mld_power_config_skip_dtim(struct iwl_mld *mld,
/* configure skip over dtim up to 900 TU DTIM interval */
skip = max_t(int, 1, 900 / dtimper_tu);
- cmd->skip_dtim_periods = skip;
- cmd->flags |= cpu_to_le16(POWER_FLAGS_SKIP_OVER_DTIM_MSK);
+ *skip_dtim_periods = skip;
+ *flags |= cpu_to_le16(POWER_FLAGS_SKIP_OVER_DTIM_MSK);
}
#define POWER_KEEP_ALIVE_PERIOD_SEC 25
-static void iwl_mld_power_build_cmd(struct iwl_mld *mld,
- struct ieee80211_vif *vif,
- struct iwl_mac_power_cmd *cmd,
- bool d3)
+static void iwl_mld_power_build_cmd_v2(struct iwl_mld *mld,
+ struct ieee80211_vif *vif,
+ struct iwl_mac_power_cmd_v2 *cmd,
+ bool d3)
{
int dtimper, bi;
int keep_alive;
@@ -238,7 +282,9 @@ static void iwl_mld_power_build_cmd(struct iwl_mld *mld,
}
if (d3) {
- iwl_mld_power_config_skip_dtim(mld, link_conf, cmd);
+ iwl_mld_power_config_skip_dtim(mld, link_conf,
+ &cmd->skip_dtim_periods,
+ &cmd->flags);
cmd->rx_data_timeout =
cpu_to_le32(IWL_MLD_WOWLAN_PS_RX_DATA_TIMEOUT);
cmd->tx_data_timeout =
@@ -259,6 +305,95 @@ static void iwl_mld_power_build_cmd(struct iwl_mld *mld,
* mac80211 will allow uAPSD. Always call iwl_mld_power_configure_uapsd
* which will look at what mac80211 is saying.
*/
+#ifdef CONFIG_IWLWIFI_DEBUGFS
+ ps_poll = mld_vif->use_ps_poll;
+#endif
+ iwl_mld_power_configure_uapsd_v2(mld, link, cmd, ps_poll);
+}
+
+static void iwl_mld_power_build_cmd(struct iwl_mld *mld,
+ struct ieee80211_vif *vif,
+ struct iwl_mac_power_cmd *cmd,
+ bool d3)
+{
+ int dtimper, bi;
+ int keep_alive;
+ struct iwl_mld_vif *mld_vif = iwl_mld_vif_from_mac80211(vif);
+ struct ieee80211_bss_conf *link_conf = &vif->bss_conf;
+ struct iwl_mld_link *link = &mld_vif->deflink;
+ bool ps_poll = false;
+ __le32 fw_id = cpu_to_le32(mld_vif->fw_id);
+
+ if (ieee80211_vif_is_mld(vif)) {
+ int link_id;
+
+ if (WARN_ON(!vif->active_links))
+ return;
+
+ /* The firmware consumes one single configuration for the vif
+ * and can't differentiate between links, just pick the lowest
+ * link_id's configuration and use that.
+ */
+ link_id = __ffs(vif->active_links);
+ link_conf = link_conf_dereference_check(vif, link_id);
+ link = iwl_mld_link_dereference_check(mld_vif, link_id);
+
+ if (WARN_ON(!link_conf || !link))
+ return;
+ }
+ dtimper = link_conf->dtim_period;
+ bi = link_conf->beacon_int;
+
+ /* Regardless of power management state the driver must set
+ * keep alive period. FW will use it for sending keep alive NDPs
+ * immediately after association. Check that keep alive period
+ * is at least 3 * DTIM
+ */
+ keep_alive = DIV_ROUND_UP(ieee80211_tu_to_usec(3 * dtimper * bi),
+ USEC_PER_SEC);
+ keep_alive = max(keep_alive, POWER_KEEP_ALIVE_PERIOD_SEC);
+
+ cmd->id_and_color = fw_id;
+ cmd->keep_alive_seconds = cpu_to_le16(keep_alive);
+
+ if (iwlmld_mod_params.power_scheme != IWL_POWER_SCHEME_CAM)
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_POWER_SAVE_ENA_MSK);
+
+ if (vif->cfg.ps && iwl_mld_tdls_sta_count(mld) == 0) {
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_POWER_MANAGEMENT_ENA_MSK);
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_ENABLE_SMPS_MSK);
+
+ /* firmware supports LPRX for beacons at rate 1 Mbps or
+ * 6 Mbps only
+ */
+ if (link_conf->beacon_rate &&
+ (link_conf->beacon_rate->bitrate == 10 ||
+ link_conf->beacon_rate->bitrate == 60)) {
+ cmd->flags |= cpu_to_le16(POWER_FLAGS_LPRX_ENA_MSK);
+ cmd->lprx_rssi_threshold = POWER_LPRX_RSSI_THRESHOLD;
+ }
+ }
+
+ if (d3) {
+ iwl_mld_power_config_skip_dtim(mld, link_conf,
+ &cmd->skip_dtim_periods,
+ &cmd->flags);
+ cmd->rx_data_timeout =
+ cpu_to_le32(IWL_MLD_WOWLAN_PS_RX_DATA_TIMEOUT);
+ cmd->tx_data_timeout =
+ cpu_to_le32(IWL_MLD_WOWLAN_PS_TX_DATA_TIMEOUT);
+ } else if (iwl_mld_vif_low_latency(mld_vif) && vif->p2p) {
+ cmd->tx_data_timeout =
+ cpu_to_le32(IWL_MLD_SHORT_PS_TX_DATA_TIMEOUT);
+ cmd->rx_data_timeout =
+ cpu_to_le32(IWL_MLD_SHORT_PS_RX_DATA_TIMEOUT);
+ } else {
+ cmd->rx_data_timeout =
+ cpu_to_le32(IWL_MLD_DEFAULT_PS_RX_DATA_TIMEOUT);
+ cmd->tx_data_timeout =
+ cpu_to_le32(IWL_MLD_DEFAULT_PS_TX_DATA_TIMEOUT);
+ }
+
#ifdef CONFIG_IWLWIFI_DEBUGFS
ps_poll = mld_vif->use_ps_poll;
#endif
@@ -268,11 +403,23 @@ static void iwl_mld_power_build_cmd(struct iwl_mld *mld,
int iwl_mld_update_mac_power(struct iwl_mld *mld, struct ieee80211_vif *vif,
bool d3)
{
- struct iwl_mac_power_cmd cmd = {};
+ int cmd_ver = iwl_fw_lookup_cmd_ver(mld->fw, MAC_PM_POWER_TABLE, 0);
- iwl_mld_power_build_cmd(mld, vif, &cmd, d3);
+ if (cmd_ver >= 3) {
+ struct iwl_mac_power_cmd cmd = {};
- return iwl_mld_send_cmd_pdu(mld, MAC_PM_POWER_TABLE, &cmd);
+ iwl_mld_power_build_cmd(mld, vif, &cmd, d3);
+ return iwl_mld_send_cmd_with_flags_pdu(mld,
+ MAC_PM_POWER_TABLE, 0,
+ &cmd, sizeof(cmd));
+ } else {
+ struct iwl_mac_power_cmd_v2 cmd = {};
+
+ iwl_mld_power_build_cmd_v2(mld, vif, &cmd, d3);
+ return iwl_mld_send_cmd_with_flags_pdu(mld,
+ MAC_PM_POWER_TABLE, 0,
+ &cmd, sizeof(cmd));
+ }
}
static void
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 402ba5dee8b2..be89b84204fb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
/*
- * Copyright (C) 2012-2014, 2018-2025 Intel Corporation
+ * Copyright (C) 2012-2014, 2018-2026 Intel Corporation
* Copyright (C) 2013-2015 Intel Mobile Communications GmbH
* Copyright (C) 2016-2017 Intel Deutschland GmbH
*/
@@ -469,7 +469,7 @@ struct iwl_mvm_vif {
struct dentry *dbgfs_slink;
struct iwl_dbgfs_pm dbgfs_pm;
struct iwl_dbgfs_bf dbgfs_bf;
- struct iwl_mac_power_cmd mac_pwr_cmd;
+ struct iwl_mac_power_cmd_v2 mac_pwr_cmd;
int dbgfs_quota_min;
bool ftm_unprotected;
#endif
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/power.c b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
index 610de29b7be0..46792c508753 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/power.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/power.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/*
- * Copyright (C) 2012-2014, 2018-2019, 2021-2025 Intel Corporation
+ * Copyright (C) 2012-2014, 2018-2019, 2021-2026 Intel Corporation
* Copyright (C) 2013-2014 Intel Mobile Communications GmbH
* Copyright (C) 2015-2017 Intel Deutschland GmbH
*/
@@ -83,7 +83,7 @@ void iwl_mvm_beacon_filter_set_cqm_params(struct iwl_mvm *mvm,
}
static void iwl_mvm_power_log(struct iwl_mvm *mvm,
- struct iwl_mac_power_cmd *cmd)
+ struct iwl_mac_power_cmd_v2 *cmd)
{
IWL_DEBUG_POWER(mvm,
"Sending power table command on mac id 0x%X for power level %d, flags = 0x%X\n",
@@ -121,7 +121,7 @@ static void iwl_mvm_power_log(struct iwl_mvm *mvm,
static void iwl_mvm_power_configure_uapsd(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
- struct iwl_mac_power_cmd *cmd)
+ struct iwl_mac_power_cmd_v2 *cmd)
{
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
enum ieee80211_ac_numbers ac;
@@ -296,7 +296,7 @@ static bool iwl_mvm_power_is_radar(struct ieee80211_bss_conf *link_conf)
static void iwl_mvm_power_config_skip_dtim(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
- struct iwl_mac_power_cmd *cmd)
+ struct iwl_mac_power_cmd_v2 *cmd)
{
struct ieee80211_bss_conf *link_conf;
unsigned int min_link_skip = ~0;
@@ -344,7 +344,7 @@ static void iwl_mvm_power_config_skip_dtim(struct iwl_mvm *mvm,
static void iwl_mvm_power_build_cmd(struct iwl_mvm *mvm,
struct ieee80211_vif *vif,
- struct iwl_mac_power_cmd *cmd)
+ struct iwl_mac_power_cmd_v2 *cmd)
{
int dtimper, bi;
int keep_alive;
@@ -466,7 +466,7 @@ static void iwl_mvm_power_build_cmd(struct iwl_mvm *mvm,
static int iwl_mvm_power_send_cmd(struct iwl_mvm *mvm,
struct ieee80211_vif *vif)
{
- struct iwl_mac_power_cmd cmd = {};
+ struct iwl_mac_power_cmd_v2 cmd = {};
iwl_mvm_power_build_cmd(mvm, vif, &cmd);
iwl_mvm_power_log(mvm, &cmd);
@@ -717,7 +717,7 @@ int iwl_mvm_power_mac_dbgfs_read(struct iwl_mvm *mvm,
int bufsz)
{
struct iwl_mvm_vif *mvmvif = iwl_mvm_vif_from_mac80211(vif);
- struct iwl_mac_power_cmd cmd = {};
+ struct iwl_mac_power_cmd_v2 cmd = {};
int pos = 0;
mutex_lock(&mvm->mutex);
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 05/15] wifi: iwlwifi: mld: call iwl_mld_free_ap_early_key() for AP only
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Avraham Stern
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Avraham Stern <avraham.stern@intel.com>
The driver supports intalling IGTK on a NAN device interface. When
the IGTK is removed, iwl_mld_free_ap_early_key() is called which
results in a warning since no links are attached to this interface.
The iwl_mld_free_ap_early_key() function should be called for AP or
IBSS interfaces only. Check the interface type before calling it.
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/mac80211.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index 4315b1b2b36b..41bc47e4e00c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -2227,7 +2227,9 @@ static void iwl_mld_set_key_remove(struct iwl_mld *mld,
}
/* if this key was stored to be added later to the FW - free it here */
- if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
+ if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE) &&
+ (vif->type == NL80211_IFTYPE_AP ||
+ vif->type == NL80211_IFTYPE_ADHOC))
iwl_mld_free_ap_early_key(mld, key, mld_vif);
/* We already removed it */
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 04/15] wifi: iwlwifi: set state to NO_FW on reset
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
On debugfs reset, set the transport FW state to NO_FW
so that the restart won't attempt to send commands,
which of course fails because the FW was killed during
the error dump.
Use iwl_trans_fw_error() now since that's effectively
the same as the old code plus setting the state.
Fixes: e5d110fec068 ("wifi: iwlwifi: pcie: fix locking on invalid TOP reset")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c | 3 +--
1 file changed, 1 insertion(+), 2 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 9f4c99dca195..e3603571bdd9 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
@@ -3201,8 +3201,7 @@ static ssize_t iwl_dbgfs_reset_write(struct file *file,
return -EINVAL;
trans->request_top_reset = 1;
}
- iwl_op_mode_nic_error(trans->op_mode, IWL_ERR_TYPE_DEBUGFS);
- iwl_trans_schedule_reset(trans, IWL_ERR_TYPE_DEBUGFS);
+ iwl_trans_fw_error(trans, IWL_ERR_TYPE_DEBUGFS);
return count;
}
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 03/15] wifi: iwlwifi: define new FSEQ TLV with MAC ID
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
Some firmware files can be used for different MACs, for example
for sc2/sc2f, yet might have different FSEQ versions. The files
will then contain multiple bigger FSEQ TLVs indicating the MAC
ID in addition to the version.
For now, since we don't parse this, define only the new format.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/fw/file.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h b/drivers/net/wireless/intel/iwlwifi/fw/file.h
index 68ddd99a9f7d..197c88c25f72 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
@@ -1064,10 +1064,15 @@ struct iwl_fw_dump_exclude {
__le32 addr, size;
};
-struct iwl_fw_fseq_bin_version {
+struct iwl_fw_fseq_bin_version_v1 {
__le32 major, minor;
}; /* FW_TLV_FSEQ_BIN_VERSION_S */
+struct iwl_fw_fseq_bin_version {
+ /* rf_id is currently unused and always zero */
+ __le32 mac_id, rf_id, major, minor;
+}; /* FW_TLV_FSEQ_BIN_VERSION_S */
+
static inline size_t _iwl_tlv_array_len(const struct iwl_ucode_tlv *tlv,
size_t fixed_size, size_t var_size)
{
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 02/15] wifi: iwlwifi: tighten flags in debugfs command sending
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Johannes Berg <johannes.berg@intel.com>
The only flags that could reasonably be used here are
CMD_WANT_SKB and CMD_ASYNC, CMD_SEND_IN_RFKILL doesn't
really make sense and CMD_BLOCK_TXQS just triggers a
warning, as does CMD_WANT_SKB | CMD_ASYNC.
Clear CMD_WANT_SKB since the response SKB isn't used
anyway, and refuse flags other than CMD_ASYNC to avoid
the warnings or other issues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/debugfs.c b/drivers/net/wireless/intel/iwlwifi/fw/debugfs.c
index ddee7c2deb36..f06978d5b5ee 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/debugfs.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/*
- * Copyright (C) 2012-2014, 2018-2024 Intel Corporation
+ * Copyright (C) 2012-2014, 2018-2024, 2026 Intel Corporation
* Copyright (C) 2013-2015 Intel Mobile Communications GmbH
* Copyright (C) 2016-2017 Intel Deutschland GmbH
*/
@@ -275,16 +275,19 @@ static ssize_t iwl_dbgfs_send_hcmd_write(struct iwl_fw_runtime *fwrt, char *buf,
goto out;
}
+ /* ignore this flag, we cannot use the response */
+ hcmd.flags &= ~CMD_WANT_SKB;
+ /* reject flags other than async, they cannot be used this way */
+ if (hcmd.flags & ~CMD_ASYNC) {
+ ret = -EINVAL;
+ goto out;
+ }
+
if (fwrt->ops && fwrt->ops->send_hcmd)
ret = fwrt->ops->send_hcmd(fwrt->ops_ctx, &hcmd);
else
ret = -EPERM;
- if (ret < 0)
- goto out;
-
- if (hcmd.flags & CMD_WANT_SKB)
- iwl_free_resp(&hcmd);
out:
kfree(data);
return ret ?: count;
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 01/15] wifi: iwlwifi: pcie: add debug print for resume flow if powered off
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Aaron Katzin, Emmanuel Grumbach
In-Reply-To: <20260512193441.2352467-1-miriam.rachel.korenblit@intel.com>
From: Aaron Katzin <aaron.katzin@intel.com>
Log when the resume flow identifies based on the
scratch register that the device was powered off.
Signed-off-by: Aaron Katzin <aaron.katzin@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/pcie/drv.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index e0be899b8fca..58a7ae33c3ff 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -1240,8 +1240,12 @@ static int _iwl_pci_resume(struct device *device, bool restore)
u32 scratch = iwl_read32(trans, CSR_FUNC_SCRATCH);
if (!(scratch & CSR_FUNC_SCRATCH_POWER_OFF_MASK) ||
- scratch == ~0U)
+ scratch == ~0U) {
device_was_powered_off = true;
+ IWL_DEBUG_WOWLAN(trans,
+ "Scratch 0x%08x indicates device was powered off\n",
+ scratch);
+ }
} else {
/*
* bh are re-enabled by iwl_trans_pcie_release_nic_access,
--
2.34.1
^ permalink raw reply related
* [PATCH iwlwifi-next 00/15] wifi: iwlwifi: updates - 2026-05-12 part2
From: Miri Korenblit @ 2026-05-12 19:34 UTC (permalink / raw)
To: linux-wireless
Hi,
More patches from our internal tree.
Thanks,
Miri
---
Aaron Katzin (1):
wifi: iwlwifi: pcie: add debug print for resume flow if powered off
Avinash Bhatt (4):
wifi: iwlwifi: Transition to basic uAPSD with MAC_PM_POWER_TABLE API
VER_3
wifi: iwlwifi: mld: add chan-load hysteresis for MLO scan triggers
wifi: iwlwifi: mld: add duplicated beacon RSSI adjustment
wifi: iwlwifi: mld: Add KUnit tests for channel-load thresholds
Avraham Stern (2):
wifi: iwlwifi: mld: call iwl_mld_free_ap_early_key() for AP only
wifi: iwlwifi: mld: add support for nan schedule config command
version 2
Daniel Gabay (3):
wifi: iwlwifi: mld: fix NAN DW end notification handler
wifi: iwlwifi: mld: add NULL check for channel in DW end handler
wifi: iwlwifi: mld: validate aux sta before flush in stop_nan
Emmanuel Grumbach (1):
wifi: iwlwifi: implement the new RSC notification
Ilan Peer (1):
wifi: iwlwifi: mld: Add support for multiple NAN Management stations
Johannes Berg (3):
wifi: iwlwifi: tighten flags in debugfs command sending
wifi: iwlwifi: define new FSEQ TLV with MAC ID
wifi: iwlwifi: set state to NO_FW on reset
.../wireless/intel/iwlwifi/fw/api/datapath.h | 9 +-
.../wireless/intel/iwlwifi/fw/api/mac-cfg.h | 55 +++++-
.../net/wireless/intel/iwlwifi/fw/api/power.h | 48 ++++-
.../net/wireless/intel/iwlwifi/fw/debugfs.c | 15 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 7 +-
drivers/net/wireless/intel/iwlwifi/mld/d3.c | 148 +++++++++++++--
drivers/net/wireless/intel/iwlwifi/mld/d3.h | 6 +-
.../net/wireless/intel/iwlwifi/mld/iface.c | 30 +--
.../net/wireless/intel/iwlwifi/mld/iface.h | 9 +-
drivers/net/wireless/intel/iwlwifi/mld/link.c | 129 ++++++++++++-
drivers/net/wireless/intel/iwlwifi/mld/link.h | 15 ++
.../net/wireless/intel/iwlwifi/mld/mac80211.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mld/mld.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mld/mlo.c | 29 ++-
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 149 ++++++++++++---
drivers/net/wireless/intel/iwlwifi/mld/nan.h | 2 +
.../net/wireless/intel/iwlwifi/mld/notif.c | 12 +-
.../net/wireless/intel/iwlwifi/mld/power.c | 177 ++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/mld/rx.c | 22 +++
drivers/net/wireless/intel/iwlwifi/mld/rx.h | 5 +-
drivers/net/wireless/intel/iwlwifi/mld/sta.c | 69 +++++--
drivers/net/wireless/intel/iwlwifi/mld/sta.h | 13 ++
.../net/wireless/intel/iwlwifi/mld/stats.c | 4 +
.../wireless/intel/iwlwifi/mld/tests/Makefile | 1 +
.../iwlwifi/mld/tests/chan_load_thresh.c | 139 ++++++++++++++
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +-
.../net/wireless/intel/iwlwifi/mvm/power.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 6 +-
.../intel/iwlwifi/pcie/gen1_2/trans.c | 3 +-
30 files changed, 993 insertions(+), 138 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/mld/tests/chan_load_thresh.c
--
2.34.1
^ permalink raw reply
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Marcus Glocker @ 2026-05-12 17:56 UTC (permalink / raw)
To: Baochen Qiang, Maxim Storetvedt
Cc: ath12k, linux-wireless, jjohnson, kvalo, manivannan.sadhasivam,
Mark Kettenis
In-Reply-To: <0b450204-9afc-4ba1-b9c5-1876b5a7078a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]
On Tue, May 12, 2026 at 11:38:06AM +0800, Baochen Qiang wrote:
>
>
> On 5/5/2026 5:08 AM, Marcus Glocker wrote:
> > Hi,
> >
> > We're porting ath12k to OpenBSD as the qwz(4) driver, targeting Samsung
> > Galaxy Book4 Edge (X1E80100 SoC, WCN7850 hw2.0). Scan, auth, 4-way
> > handshake all complete; ~2 seconds after WPA2 AUTHORIZE the WCN7850
> > firmware crashes deterministically with:
> >
> > dlpager_main.c:147 Non Page Fault Exception cause code 0x 23
> > at Address: 0x 1792000
> >
> > Cause code 0x23 isn't a valid arm64 exception -- the fault is on the
> > WCN7850's on-die Hexagon Q6 DSP, with QURT's generic exception handler
> > (which happens to live in dlpager_main.c) printing it. So this is not
> > a host CPU fault.
> >
> > Per the RDDM segment table (at the start of the dump), VA 0x01792000
> > is the start of the chip's WLAON_DUMP region (size 0x820). The Q6 is
> > trying to read its own always-on hardware state region and the chip
> > refuses the access.
> >
> > (Samsung, Asus, Honor) with multiple FW builds. Currently testing
> > with WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> > (fw 0x110cffff, 2025-06-25) -- the exact blob a Linux ath12k user
> > runs successfully on the identical Samsung hardware. Same board-2.bin,
> > same compiled DTB (upstream hamoa.dtsi based).
> >
> > We've field-compared qwz against ath12k and ruled out (byte-level or
> > wire-level):
> >
> > * QMI host_cap, m3_info, wlan_cfg, wlan_ini, bdf_download (all
> > fields including ce_config, svc_to_ce_map, shadow_reg_v3,
> > feature_list, m3 paddr/size, nm_modem)
> > * MHI bringup ordering (BHI -> wait SBL EE -> wait M0 -> BHIE)
> > * BHI/BHIE DMA coherency
> > * ASPM disable before MHI start
> > * WLAON_WARM_SW_ENTRY zeroing + QFPROM_PWR_CTRL VDD4BLOW clear
> > * static_window_map=false + window-bank register init
> > * Per-chunk vs monolithic respond_mem allocation
> > * WMI_PEER_MIMO_PS_STATE = WMI_PEER_SMPS_PS_NONE (added matching
> > ath12k_setup_peer_smps; doesn't help)
> > * FW image variation (c5 and c7 both fail identically)
> >
> > Specifically NOT involved (we have evidence either way):
> >
> > * Gunyah -- X1E80100 is reportedly run in EL2 without Gunyah by
> > users where ath12k works; so Gunyah isn't programming WLAON
> > access for the Q6.
> > * SMMU / pcie_smmu -- pcie_smmu is status="reserved" upstream,
> > pcie4 has no iommus property; PCIe DMA bypasses SMMU.
> > * SCM/PAS -- ath12k's PCIe path makes no qcom_scm_* calls.
> >
> > Question: what subsystem inside the WCN7850 firmware touches the
> > WLAON region at 0x01792000 around 2 seconds after the host sends
> > WMI_PEER_AUTHORIZE? And what host-side configuration (WMI command,
> > HTT message, MHI state, etc.) primes that path so the access
> > succeeds on Linux?
> >
> > Even a pointer at the right Linux code path or the right FW-side
> > component would unblock us. We have full RDDM dumps and dmesg
> > captures available; happy to share off-list or as attachments.
>
> please help collect ath12k successful dmesg log and qwz failed dmesg log for compare.
>
> Please enable verbose ath12k log when loading ath12k driver:
>
> If you are using the latest upstream ath12k:
>
> sudo modprobe ath12k debug_mask=0xffffffff
> sudo modprobe ath12k_wifi7
>
> If you are using an old ath12k:
>
> sudo modprobe ath12k debug_mask=0xffffffff
>
> >
> > Thanks,
> > Marcus
> >
>
Hi Baochen,
Thanks for coming back on this topic.
Attached the OpenBSD dmesg, with full ath12k driver debug logging
enabled, plus the resulting RDDM binary after the firmware crash.
The command sequence on OpenBSD to re-produce that was:
ifconfig qwz0 up # Bring the ath12k device up
ifconfig qwz0 scan # Scan for networks
ifconfig qwz0 nwid nazgul wpakey xxx # Start association
Hi Max,
Since you have Linux running on exactly the same Samsung Galaxy Book4
Edge 14" laptop, where ath12k works, would you be so kind and also
provide the dmesg output showing an successful association with the
ath12k driver debug logging enabled? See above how to enable that.
That would be very helpful!
Thanks and Regards,
Marcus
[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gunzip, Size: 83823 bytes --]
[-- Attachment #3: qwz0-rddm.bin.gz --]
[-- Type: application/x-gunzip, Size: 2103951 bytes --]
^ permalink raw reply
* pull-request: ath-current-20260512
From: Jeff Johnson @ 2026-05-12 14:28 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit 7666dbb1bacc4ba522b96740cba7283d243d16e1:
wifi: cfg80211: advance loop vars in cfg80211_merge_profile() (2026-05-08 09:20:03 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-current-20260512
for you to fetch changes up to 54a5b38e4396530e5b2f12b54d3844e860ab6784:
wifi: ath10k: skip WMI and beacon transmission when device is wedged (2026-05-12 07:00:00 -0700)
----------------------------------------------------------------
ath.git update for v7.1-rc5
In ath10k, avoid sending any commands to firmware when it is wedged.
In ath11k, fix WMI buffer leaks on error conditions.
----------------------------------------------------------------
Kang Yang (1):
wifi: ath10k: skip WMI and beacon transmission when device is wedged
Nicolas Escande (3):
wifi: ath11k: fix error path leaks in some WMI WOW calls
wifi: ath11k: fix error path leaks in some WMI calls
wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
drivers/net/wireless/ath/ath10k/wmi.c | 15 ++--
drivers/net/wireless/ath/ath11k/testmode.c | 1 +
drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++++-----
3 files changed, 120 insertions(+), 27 deletions(-)
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath10k: skip WMI and beacon transmission when device is wedged
From: Jeff Johnson @ 2026-05-12 14:02 UTC (permalink / raw)
To: ath10k, Kang Yang; +Cc: linux-wireless
In-Reply-To: <20260428061737.37-1-kang.yang@oss.qualcomm.com>
On Tue, 28 Apr 2026 14:17:37 +0800, Kang Yang wrote:
> In ath10k_wmi_cmd_send(), the current code detects ATH10K_STATE_WEDGED
> and sets ret to -ESHUTDOWN, but still proceeds to transmit pending
> beacons and calls ath10k_wmi_cmd_send_nowait().
>
> This can lead to incorrect behavior, as WMI commands and beacons are
> still sent after the device has been marked as wedged, and the original
> -ESHUTDOWN return value may be overwritten by the result of the send
> path.
>
> [...]
Applied, thanks!
[1/1] wifi: ath10k: skip WMI and beacon transmission when device is wedged
commit: 54a5b38e4396530e5b2f12b54d3844e860ab6784
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/3] fix leaks in some WMI error path
From: Jeff Johnson @ 2026-05-12 14:02 UTC (permalink / raw)
To: ath11k, Nicolas Escande; +Cc: linux-wireless
In-Reply-To: <20260506134240.2284016-1-nico.escande@gmail.com>
On Wed, 06 May 2026 15:42:37 +0200, Nicolas Escande wrote:
> So this is similar work to what has been posted here [0] for ath12k.
>
> When we use the pattern 'return ath11k_wmi_cmd_send(...)' without
> explicitly checking the return value we fail to free the allocated skb.
>
> This has been split into 2 patches per Jeff's guidance to hopefully
> ease the backporting process.
>
> [...]
Applied, thanks!
[1/3] wifi: ath11k: fix error path leaks in some WMI WOW calls
commit: 55dda532bbc261aef495e403c8900c5e2ab5fa34
[2/3] wifi: ath11k: fix error path leaks in some WMI calls
commit: ebad0b48996fd4919c36bbcb07289d37d046de74
[3/3] wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()
commit: 7320d6eb861e9913193a7801834c661381756a79
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] treewide: fixup gfp_t printks
From: Brendan Jackman @ 2026-05-12 12:58 UTC (permalink / raw)
To: Brendan Jackman, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Stanislaw Gruszka,
Alexander Potapenko, Marco Elver, Dmitry Vyukov, Andrew Morton,
Allison Henderson, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: dri-devel, linux-kernel, linux-wireless, kasan-dev, linux-mm,
netdev, linux-rdma, rds-devel
In-Reply-To: <20260326-gfp64-v2-0-d916021cecdf@google.com>
On Thu Mar 26, 2026 at 12:31 PM UTC, Brendan Jackman wrote:
> This patchset used to be about switching gfp_t to unsigned long. That is
> probably not gonna happen any more but while writing it I found these
> cleanups that seem worthwhile regardless.
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
> Changes in v2:
> - Drop gfp_t changes
> - Add correct CCs
> - Add minor fixups to preexisting code spotted by AI review
> - Link to v1: https://lore.kernel.org/r/20260319-gfp64-v1-0-2c73b8d42b7f@google.com
>
> ---
> Brendan Jackman (4):
> drm/managed: Use special gfp_t format specifier
> iwlegacy: 3945-mac: Fixup allocation failure log
> mm/kfence: Use special gfp_t format specifier
> net/rds: Use special gfp_t format specifier
>
> drivers/gpu/drm/drm_managed.c | 4 ++--
> drivers/net/wireless/intel/iwlegacy/3945-mac.c | 4 ++--
> mm/kfence/kfence_test.c | 2 +-
> net/rds/tcp_recv.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
> ---
> base-commit: c369299895a591d96745d6492d4888259b004a9e
> change-id: 20260319-gfp64-7a970a80ba4e
>
> Best regards,
Hi all,
Any chance someone can take these?
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Thorsten Leemhuis @ 2026-05-12 11:30 UTC (permalink / raw)
To: Johannes Berg, Ping-Ke Shih
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <522d09d5fad2fdebc89419a7e75b89ff14de162a.camel@sipsolutions.net>
On 5/12/26 11:36, Johannes Berg wrote:
> On Tue, 2026-05-12 at 10:54 +0200, Thorsten Leemhuis wrote:
>>>> You
>>>> can cherry-pick or directly apply the fix to a pending branch (or even
>>>> ask Linus to merge it directly from the list, but that is likely not
>>>> worth it here) and git will normally later notice this and fully
>>>> automatically handle everything when the fix comes in again during the
>>>> next merge window.
>>>
>>> I know git can handle that, but is it an acceptable practice for single one
>>> commit to appear twice?
>>
>> Depends on whom you ask. I'd say: It's kinda normal. It's best avoided
>> if there is no need, but if there is a need (like here) it's fine. And
>> some subsystems it even happens regularly iirc.
> > FWIW, it's generally frowned upon and actually uncommon enough that
> linux-next actively warns about it [1] (or at least used to?), so I
> wouldn't really say your description here is all that accurate.
>
> [1] https://lore.kernel.org/lkml/?q=%22duplicate+patch+in+the%22
>
> What does happen fairly frequently is the same immutable commit getting
> merged through different branches, but that's a single commit, not the
> same change being committed twice.
Well, that made me look up my "regularly iirc" claim. Now I remember
where I got that from: the cherry-picking (which results in a second
commit-id) the DRM subsystem regularly did:
https://lwn.net/Articles/1005222/
That's was early 2025, so the workflows there might have changed in
between due to the criticism. But from a quick 'git log --grep "(cherry
picked from commit"' in mainline it doesn't look like it did. Here is
one example of a commit that made it into 7.0 that sits with a different
commit-id in -next a second time:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=Avoid+memory+allocations+in+xe_device_declare_wedged
b08ceb44386680 ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [next-20260330]
56b7432b7e8e6a ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [v7.0-rc7]
Here are a few from the current cycle:
0d831487b5be0a ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2")
[next-20260506]
4e02e0afa95f69 ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2") [v7.1-rc3]
1fc6c8ab45dbee ("drm/amdgpu/userq: fix access to stale wptr mapping")
[next-20260506]
6da7b1242da445 ("drm/amdgpu/userq: fix access to stale wptr mapping")
[v7.1-rc3]
d12d05c4bc4c15 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [next-20260506]
81665e35f143d9 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [v7.1-rc3]
d9af8263b82b6e ("drm/amdgpu: zero-initialize GART table on allocation")
[next-20260506]
e6c2e6c2e1fa06 ("drm/amdgpu: zero-initialize GART table on allocation")
[v7.1-rc3]
I found a few dozen more. But this is not my area of expertise, so
please correct me if I'm missing something.
In the end I don't care about all that. I just think it would be good to
get this regression fixed in mainline this cycle. And I suspect Linus
wants that, too. For example due to previous discussions like this:
https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/
Ciao, Thorsten
^ permalink raw reply
* RE: [PATCH v2 0/3] wifi: iwlwifi: add Device Tree hardware integration information
From: Bhatt, Avinash @ 2026-05-12 10:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree@vger.kernel.org, linux-wireless@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
johannes@sipsolutions.net, Korenblit, Miriam Rachel,
linux-kernel@vger.kernel.org, Guetta, Kobi, Grumbach, Emmanuel
In-Reply-To: <20260505-crouching-albatross-of-beauty-a5ac6b@quoll>
Hi Krzysztof,
Thank you for the review. Please find our response inline below.
On Mon, May 04, 2026 at 12:53:24PM +0300, Krzysztof Kozlowski wrote:
> Please provide link to any upstream DTS user of this binding, either
> complete or work in progress.
We have OEM partners waiting for this binding layout to be finalized
before they proceed with their DTS work. Our intent is to have the
schema reviewed and accepted by the DT maintainers first — sharing a
binding that may still undergo structural changes with OEMs would create
unnecessary churn on their side.
OEM partners are targeting platforms that depend on this binding. They
are waiting for the schema to be finalized before proceeding with their
DTS work, and whether they upstream that DTS is ultimately their
decision.
If a DTS user is strictly required for the binding to be merged, we
understand and accept that requirement — however, since OEM upstreaming
is outside our control, we would greatly appreciate an early indication
of whether the schema direction is acceptable before we distribute it
further. Any feedback or provisional acceptance at this stage would be
very helpful.
We are actively addressing all the review comments from v2 and plan to
send v3 shortly.
Best Regards,
Avinash
-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 05 May 2026 14:50
To: Bhatt, Avinash <avinash.bhatt@intel.com>
Cc: devicetree@vger.kernel.org; linux-wireless@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; johannes@sipsolutions.net; Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; linux-kernel@vger.kernel.org; Guetta, Kobi <kobi.guetta@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH v2 0/3] wifi: iwlwifi: add Device Tree hardware integration information
On Mon, May 04, 2026 at 12:53:24PM +0300, Avinash Bhatt wrote:
> Add Device Tree support for Intel Wi-Fi hardware integration
> information on platforms that do not provide UEFI variables or ACPI methods.
>
> Patch 1/3 adds the DT binding schema for the Intel iwlwifi compatible
> node. Patches 2/3 and 3/3 add the driver infrastructure and integrate
> DT as the lowest-priority fallback after UEFI and ACPI.
Please provide link to any upstream DTS user of this binding, either complete or work in progress.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 2/3] wifi: iwlwifi: dt: add Device Tree BIOS configuration infrastructure
From: Bhatt, Avinash @ 2026-05-12 10:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree@vger.kernel.org, linux-wireless@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
johannes@sipsolutions.net, Korenblit, Miriam Rachel,
linux-kernel@vger.kernel.org, Guetta, Kobi, Grumbach, Emmanuel
In-Reply-To: <20260505-sincere-electric-lobster-2a7bc3@quoll>
Hi Krzysztof,
Thank you for the review. Please find our response inline below.
We have made several changes in the driver as part of v3 and will be
sending it shortly.
On Mon, May 04, 2026 at 12:53:26PM +0300, Krzysztof Kozlowski wrote:
> +static const char *dsm_func_to_prop_name(enum iwl_dsm_funcs func) {
> + switch (func) {
> + case DSM_FUNC_DISABLE_SRD: return IWL_DT_PROP_SRD;
> + case DSM_FUNC_ENABLE_6E: return IWL_DT_PROP_6E_UHB;
> ...
>
> Pointless function and only making DT ABI checks difficult. Drop.
> Don't invent API wrappers or other HAL over simple calls to OF or
> device API.
> Drop also ALL defines and use OF API like EVERY other driver.
Fixed in v3. Removed dsm_func_to_prop_name() and all IWL_DT_PROP_*
defines. iwl_dt_get_dsm() now dispatches via a direct switch on the
function index to individual per-property functions (iwl_dt_get_srd(),
iwl_dt_get_6e_uhb(), etc.), each calling of_property_read_*() directly
with the literal property string — consistent with how every other
driver uses the OF API.
Best Regards,
Avinash
-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 05 May 2026 14:48
To: Bhatt, Avinash <avinash.bhatt@intel.com>
Cc: devicetree@vger.kernel.org; linux-wireless@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; johannes@sipsolutions.net; Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; linux-kernel@vger.kernel.org; Guetta, Kobi <kobi.guetta@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH v2 2/3] wifi: iwlwifi: dt: add Device Tree BIOS configuration infrastructure
On Mon, May 04, 2026 at 12:53:26PM +0300, Avinash Bhatt wrote:
> +
> +/*
> + * Mapping from DSM function index to Device Tree property name.
> + * Returns the DT property name for a given DSM function, or NULL if
> +the
> + * function has no Device Tree representation.
> + */
> +static const char *dsm_func_to_prop_name(enum iwl_dsm_funcs func) {
> + switch (func) {
> + case DSM_FUNC_DISABLE_SRD: return IWL_DT_PROP_SRD;
> + case DSM_FUNC_ENABLE_6E: return IWL_DT_PROP_6E_UHB;
> + case DSM_FUNC_REGULATORY_CONFIG: return IWL_DT_PROP_REG_SPECIAL;
> + case DSM_FUNC_ACTIVATE_CHANNEL: return IWL_DT_PROP_ACTIVATE_CH;
> + case DSM_FUNC_FORCE_DISABLE_CHANNELS:
> + return IWL_DT_PROP_FORCE_DISABLE_CH;
> + case DSM_FUNC_ENABLE_11BE: return IWL_DT_PROP_11BE;
> + default: return NULL;
Pointless function and only making DT ABI checks difficult. Drop.
Don't invent API wrappers or other HAL over simple calls to OF or device API.
Drop also ALL defines and use OF API like EVERY other driver. This is not a special place.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 1/3] dt-bindings: net: wireless: intel,iwlwifi: add binding
From: Bhatt, Avinash @ 2026-05-12 9:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree@vger.kernel.org, linux-wireless@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
johannes@sipsolutions.net, Korenblit, Miriam Rachel,
linux-kernel@vger.kernel.org, Guetta, Kobi, Grumbach, Emmanuel
In-Reply-To: <20260505-nano-seal-of-speed-7d5bc8@quoll>
Hi Krzysztof,
Thank you for the detailed review. Please find our responses inline below.
We are actively addressing all comments and plan to send v3 shortly.
On Mon, May 04, 2026 at 12:53:25PM +0300, Krzysztof Kozlowski wrote:
> On Mon, May 04, 2026 at 12:53:25PM +0300, Avinash Bhatt wrote:
> > Add a devicetree schema binding for Intel discrete Wi-Fi 7 BE200 PCIe
> > adapters.
>
> A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
> prefix is already stating that these are bindings.
> Just describe hardware.
Fixed in v3. Subject is now:
"dt-bindings: net: wireless: Add Intel Wi-Fi 7 BE200 PCIe adapter"
> > The binding documents OEM platform configuration properties for
>
> No, describe hardware.
Fixed in v3. Commit body now describes the BE200 hardware directly.
> > +++ b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
>
> Filename should match actual device compatibles. iwlwifi is driver, so
> not really relevant here.
Thank you for the guidance. Looking at the other bindings in the same
directory, we see two naming conventions coexist:
- vendor,chip - e.g. brcm,bcm4329-fmac.yaml, marvell,sd8787.yaml
- vendor,driver - e.g. qca,ath9k.yaml, qcom,ath10k.yaml,
qcom,ath11k-pci.yaml, qcom,ath12k.yaml
(where ath9k, ath10k, ath11k, ath12k are driver
names, not chip names)
None of the existing wireless bindings use pciVVVV,DDDD.yaml as a
filename. Our intel,iwlwifi.yaml follows the vendor,driver pattern used
by the Qualcomm bindings. We also anticipate that future Intel Wi-Fi
devices - supported by the same iwlwifi driver - will use this same
binding, making the driver-aligned name forward-compatible.
Could you please point us to any guidance document that specifies
pciVVVV,DDDD.yaml as the required convention for PCIe device bindings,
or clarify whether intel,iwlwifi.yaml is acceptable given the above
precedent?
> > +title: Intel iwlwifi PCIe Wi-Fi devices
>
> There is no such thing as "iwlwifi" device. Again, describe hardware.
Fixed in v3. Title is now "Intel Wi-Fi 7 BE200 PCIe adapter".
> > + Revision 3 layout: 4 chains x 12 subbands = 50 cells total.
> > + Header (2 cells): ...
> > + Subband index to frequency range mapping: ...
>
> Don't invent your own syntax. Drop. There are no other bindings using
> it, so why are you coming with something completely new?
Fixed in v3. The revision header cell and its const: 0 constraint have
been removed from all properties. Property descriptions remain as plain
prose bit and subband listings - the structured table headers with
revision fields and internal layout annotations are gone.
> > + [0] revision - structure revision, must be 0x00
>
> What? If it is 0 then just drop it. Same comments everywhere else.
Fixed in v3. Revision cells removed from all properties. Each property
is now a scalar uint32 or a plain fixed-size array with no revision
header.
> > + [1] value - channel configuration:
> > + 0 = active scan permitted
> > + 1 = passive scan only
> > + 2 = SRD channels fully disabled
>
> I have doubts this is regulatory/certification property.
intel,srd controls the operating mode of the ETSI 5.8 GHz Short Range
Device (SRD) band - whether the adapter performs active scanning,
passive scanning, or disables operation in that band entirely. This is a
platform-level OEM configuration: ETSI EN 301 893 and its country-level
transpositions impose per-country restrictions on the 5.8 GHz SRD
sub-band, and OEMs must set this property once per product to reflect
the regulatory certification of the platform. It is not a runtime driver
feature toggle - it is a system integrator constraint that determines
which regulatory mode the radio operates in for that band.
> > + - items:
> > + - const: 0
>
> Drop
Fixed in v3. Revision cell dropped. intel,srd is now a plain string
property.
> > + - enum: [0, 1, 2]
>
> Use string
Fixed in v3. Changed to:
enum: [active-scan, passive-scan, disabled]
> > + bit 26: reserved, must be 0
>
> Bindings CANNOT be reserved.
>
> > + bit 28: reserved, must be 0
>
> NAK
Fixed in v3. Removed all "reserved, must be 0" annotations. Bits 26 and
28 have no assigned meaning and are simply absent from the binding - the
binding only documents bits that are defined.
> > + [0] revision - structure revision, must be 0x00 (regulatory-special)
>
> NAK
Fixed in v3. Revision cell removed.
> > + - items:
> > + - const: 0
>
> No. If it is const, then it is implied by compatible.
Fixed in v3. Removed const: 0 from all allOf/items across all
properties.
> > +required:
> > + - compatible
> > + - reg
>
> Missing ref to ieee80211 schema.
Fixed in v3. Added:
allOf:
- $ref: /schemas/net/wireless/ieee80211.yaml#
Best Regards,
Avinash
-----Original Message-----
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: 05 May 2026 14:46
To: Bhatt, Avinash <avinash.bhatt@intel.com>
Cc: devicetree@vger.kernel.org; linux-wireless@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; johannes@sipsolutions.net; Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>; linux-kernel@vger.kernel.org; Guetta, Kobi <kobi.guetta@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: net: wireless: intel,iwlwifi: add binding
On Mon, May 04, 2026 at 12:53:25PM +0300, Avinash Bhatt wrote:
> Add a devicetree schema binding for Intel discrete Wi-Fi 7 BE200 PCIe
> adapters.
A nit, subject: drop second/last, redundant "binding". The "dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Just describe hardware.
>
> The binding documents OEM platform configuration properties for
No, describe hardware.
> platforms that use Device Tree instead of platform firmware methods.
> All properties mirror the existing equivalents in structure and
> semantics, covering SAR power limits (intel,wrds),
> 6 GHz AP type support (intel,uats), static power limit (intel,splc),
> channel puncturing (intel,wcpe), 320 MHz per-MCC enablement
> (intel,wbem), ETSI SRD channel configuration (intel,srd), 6-7 GHz UHB
> country enable bitmask (intel,6e-uhb), and additional regulatory
> override properties.
>
>
> Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
> ---
> .../bindings/net/wireless/intel,iwlwifi.yaml | 430
> ++++++++++++++++++
> 1 file changed, 430 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
> b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yaml
> new file mode 100644
> index 000000000000..210063c6183d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/intel,iwlwifi.yam
> +++ l
Filename should match actual device compatibles. iwlwifi is driver, so not really relevant here.
> @@ -0,0 +1,430 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> +(c) 2026 Intel Corporation %YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/wireless/intel,iwlwifi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel iwlwifi PCIe Wi-Fi devices
There is no such thing as "iwlwifi" device. Google for it - I see "Intel(r) Wireless Wi-Fi Drivers for Linux".
Again, describe hardware.
> +
> +maintainers:
> + - Avinash Bhatt <avinash.bhatt@intel.com>
> +
> +description:
> + Intel iwlwifi IEEE 802.11be discrete Wi-Fi adapters connected over PCIe.
> +
> +properties:
> + compatible:
> + enum:
> + - pci8086,272b
> +
> + reg:
> + maxItems: 1
> +
> + intel,wrds:
> + description: |
> + Wi-Fi Regulatory Domain Settings (WRDS). SAR (Specific Absorption Rate)
> + transmit power limits per antenna chain and frequency subband. Values
> + are 8-bit unsigned in units of 0.125 dBm.
> +
> + Revision 3 layout: 4 chains x 12 subbands = 50 cells total.
> + Chain A and Chain B are the two physical antenna paths; CDB Chain A
> + and CDB Chain B carry separate limits for simultaneous dual-band
> + operation.
> +
> + Header (2 cells):
> + [0] revision - structure revision, must be 0x03
> + [1] mode - bit 0: 0 = SAR disabled, 1 = SAR enabled;
> + bits [8:1]: set to 0
> +
> + Followed by 4 chains in order: chain_a, chain_b, cdb_chain_a,
> + cdb_chain_b, each containing 12 subband values:
> +
> + Subband index to frequency range mapping:
> + [0] 2.4 GHz ch 1-13 (2412-2472 MHz)
> + [1] 5 GHz ch 36-64 (5180-5320 MHz, UNII-1/2)
> + [2] 5 GHz ch 68-96 (5340-5480 MHz, UNII-2)
> + [3] 5 GHz ch 100-144 (5500-5720 MHz, UNII-2e)
> + [4] 5 GHz ch 149-188 (5745-5940 MHz, UNII-3/4)
> + [5] 6 GHz ch 1-45 (5955-6175 MHz, UNII-5 lower)
> + [6] 6 GHz ch 49-93 (6195-6415 MHz, UNII-5 upper)
> + [7] 6 GHz ch 97-115 (6435-6525 MHz, UNII-6)
> + [8] 6 GHz ch 117-151 (6535-6705 MHz, UNII-7 lower)
> + [9] 6 GHz ch 153-183 (6715-6865 MHz, UNII-7 upper)
> + [10] 6 GHz ch 185-233 (6875-7115 MHz, UNII-8)
> + [11] 6 GHz ch 237-253 (7135-7215 MHz, UNII-9)
> + allOf:
Don't invent your own syntax. Drop. There are no other bindings using it, so why are you coming with something completely new?
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - minItems: 50
> + maxItems: 50
> +
> + intel,uats:
> + description: |
> + UHB (Ultra High Band / 6 GHz) AP Type Support (UATS). Per-country
> + enablement matrix for 6 GHz AP types. Uses byte array format
> + (DTS [ ... ] notation).
> +
> + In the 6 GHz band, regulatory rules differ per country and per AP
> + type: AFC (Standard Power), LPI (Low Power Indoor), and VLP (Very
> + Low Power). This matrix encodes which AP types are permitted to
> + operate in each country.
> +
> + Revision 1 layout (339 bytes total):
> + [0] revision - structure revision, must be 0x01
> + [1+] country_map - 338-byte matrix encoding AP type allowances
> + per country.
> +
> + Countries are identified by their ISO 3166-1
> + alpha-2 code (two letters, A-Z each). The
> + matrix covers all 26x26 = 676 possible
> + two-letter combinations (AA..ZZ), most of
> + which are unused (set to 0x0).
> +
> + Each country entry is 4 bits (a nibble). Two
> + entries are packed per byte: the low nibble
> + holds the even-indexed entry, the high nibble
> + holds the odd-indexed entry. For example,
> + byte value 0x53 means: entry[even]=0x3,
> + entry[odd]=0x5.
> +
> + The matrix is stored column-major by first
> + letter: all 26 second-letter variants for
> + first letter 'A' occupy bytes [0..12], then
> + first letter 'B' occupies bytes [13..25],
> + and so on for all 26 first letters.
> + 26 columns x 13 bytes = 338 bytes total.
> +
> + Each 4-bit nibble encodes AP type allowances
> + for one country:
> + bit 0: AFC (Standard Power AP) allowed
> + bit 1: VLP (Very Low Power AP) allowed
> + bit 2: LPI (Low Power Indoor AP) allowed
> + bit 3: reserved, must be 0
> +
> + Note: each bit is only effective when the
> + corresponding control bit in intel,6e-uhb
> + is also set (bit 30 for AFC, bit 29
> + for VLP, bit 31 for LPI country-by-country
> + mode).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint8-array
> + - minItems: 339
> + maxItems: 339
> +
> + intel,srd:
> + description: |
> + ETSI 5.8 GHz SRD (Short Range Device) channel configuration.
> + Controls how the driver handles the 5725-5875 MHz (5.8 GHz) SRD
> + channels in ETSI regulatory domains.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
What? If it is 0 then just drop it. Same comments everywhere else.
> + [1] value - channel configuration:
> + 0 = active scan permitted (default behaviour)
> + 1 = passive scan only; device may associate and
> + transfer data but must not transmit probe
> + requests on SRD channels
> + 2 = SRD channels fully disabled; the device must
> + not scan, associate, or operate on any of the
> + 5725-5875 MHz SRD channels
I have doubts this is regulatory/certification property.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
Drop
> + - enum: [0, 1, 2]
Use string
> +
> + intel,6e-uhb:
> + description: |
> + 6-7 GHz Ultra-High Band (UHB) per-country enable bitmask.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] bitmap - UHB enablement control:
> + bit 0: override control; 0 = use device defaults,
> + 1 = force-disable all countries not
> + explicitly enabled in bits 1-25
> + bits 1-25: per-country/region enable flags:
> + bit 1 = USA
> + bit 2 = Rest of World (ROW)
> + bit 3 = EU
> + bit 4 = South Korea
> + bit 5 = Brazil
> + bit 6 = Chile
> + bit 7 = Japan
> + bit 8 = Canada
> + bit 9 = Morocco
> + bit 10 = Mongolia
> + bit 11 = Malaysia
> + bit 12 = Saudi Arabia
> + bit 13 = Mexico
> + bit 14 = Nigeria
> + bit 15 = Thailand
> + bit 16 = Singapore
> + bit 17 = Taiwan
> + bit 18 = South Africa
> + bit 19 = Philippines
> + bit 20 = Serbia
> + bit 21 = Indonesia
> + bit 22 = Azerbaijan
> + bit 23 = Paraguay
> + bit 24 = Vietnam
> + bit 25 = India
> + bit 26: reserved, must be 0
Bindings CANNOT be reserved.
> + bit 27: enable VLP active scan, SoftAP, and
> + P2P-GO operation in Japan
> + bit 28: reserved, must be 0
NAK
> + bit 29: enable VLP (Very Low Power) mode per
> + country-by-country table
> + bit 30: enable AFC (Standard Power) mode per
> + country-by-country table
> + bit 31: LPI override mode; 0 = use grouping
> + mechanism, 1 = use country-by-country table
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
No. If it is const, then it is implied by compatible.
> + - {}
> +
> + intel,regulatory-special:
> + description: |
> + Regulatory Special Configurations.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
NAK
> + [1] bitmap - configuration flags:
> + bits 0-3: reserved, must be 0
> + bit 4 = Australia UHB extension
> + bits 5-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> + intel,activate-channel:
> + description: |
> + Indoor channel activation bitmask. Sets specific frequency bands to
> + active (rather than passive or disabled) when the platform is
> + confirmed to be operating indoors.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] bitmap - per-region indoor activation flags:
> + bit 0 = enable EU U-NII-1 (5.2 GHz) for indoors only
> + bit 1 = enable Japan U-NII-1 (5.2 GHz) for indoors only
> + bit 2 = enable China Mainland U-NII-1 (5.2 GHz)
> + for indoors only
> + bit 3 = enable USA U-NII-4 (5.9 GHz) for indoors only
> + bit 4 = enable WW U-NII-1 (5.2 GHz) for indoors in any
> + country where the band is permitted
> + bit 5 = enable Canada U-NII-4 (5.9 GHz) for indoors only
> + bit 6 = enable USA + Canada + WW U-NII-4 (5.9 GHz) for
> + indoors only
> + bits 7-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> + intel,force-disable-channels:
> + description: |
> + Selective Wi-Fi band force-disable bitmask. Allows the platform to
> + permanently disable specific frequency bands regardless of regulatory
> + domain.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] bitmap - per-band force-disable flags:
> + bit 0 = force disable 2.4 GHz (channels 1-13)
> + bit 1 = force disable 5.2 GHz (channels 36-48)
> + bit 2 = force disable 5.3 GHz (channels 52-64)
> + bit 3 = force disable 5.5 GHz (channels 100-144)
> + bit 4 = force disable 5.8 GHz (channels 149-165)
> + bit 5 = force disable 5.9 GHz (channels 169-177)
> + bit 6 = force disable 6.2 GHz (channels 1-93)
> + bit 7 = force disable 6.5 GHz (channels 97-113)
> + bit 8 = force disable 6.6 GHz (channels 117-153)
> + bit 9 = force disable 6.8 GHz (channels 157-185)
> + bit 10 = force disable 7.0 GHz (channels 185-233)
> + bits 11-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> + intel,11be:
> + description: |
> + 802.11be (Wi-Fi 7) per-country enable bitmask. Controls whether
> + 802.11be operation is permitted in specific countries.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] bitmap - per-country enable flags:
> + bit 0 = enable 802.11be in China (CB/CN)
> + bit 1 = enable 802.11be in South Korea
> + bits 2-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> + intel,splc:
> + description: |
> + Wi-Fi Static Power Limit Capabilities (SPLC). Sets the platform thermal
> + power limit for the Wi-Fi core in mW. Omit this property entirely if
> + no platform power limit applies; the device will use its certified
> + maximum in that case.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] power_limit - maximum platform power budget in mW, must be
> + non-zero (a zero value is equivalent to omitting
> + the property)
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - minimum: 1
> +
> + intel,wcpe:
> + description: |
> + Wi-Fi Channel Puncturing Enablement (WCPE). Enables 802.11be channel
> + puncturing for specific regulatory domains.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] puncturing - per-country enable bitmask:
> + bit 0: 1 = channel puncturing enabled for USA
> + bit 1: 1 = channel puncturing enabled for Canada
> + bits 2-31: reserved, must be 0
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> + intel,wbem:
> + description: |
> + Wi-Fi 320 MHz Bandwidth Enablement per MCC (WBEM). Controls whether
> + 320 MHz operation is permitted in specific countries.
> +
> + Layout (2 cells):
> + [0] revision - structure revision, must be 0x00
> + [1] wifi320mhz_mcc - per-country enable bitmask:
> + bit 0: 1 = 320 MHz enabled for Japan
> + bit 1: 1 = 320 MHz enabled for South Korea
> + bits 2-31: reserved, must be 0
> +
> + Each bit takes effect only if the installed
> + module is certified for 320 MHz in that country.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + - const: 0
> + - {}
> +
> +required:
> + - compatible
> + - reg
> +
Missing ref to ieee80211 schema.
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* bcma: endianness problem chipcommon access soc bcm6362
From: Alessio Ferri @ 2026-05-12 9:41 UTC (permalink / raw)
To: zajec5@gmail.com; +Cc: linux-wireless, linux-mips
Hi Rafał,
Sorry for the multiple emails, having trouble sending plain text with gmail.
I am working on an OpenWrt port for the D-Link DSL-3580L (BCM6362 SoC,
big-endian MIPS host, 4352 variant mini pcie for ac).
project here https://github.com/aleferri/openwrt-dsl3580l
While testing I ran into an endianness assumption inside bcma.
It uses readl()/writel() everywhere, which uses "device little-endian"
convention
they go through le32_to_cpu(), so on a BE host they swap bytes.
But on this SoC the AXI bus is big-endian, so readl() swaps them and
bus scanning sees garbage.
Evidence from a small diagnostic ko module that i asked claude to
create, dumps the SHIM at 0x10007000 and the AXI chipcommon at
0x10004000 side by side:
axi @0x10004000 +0x00 CC_ID readl=0x62630122 ioread32be=0x22016362
shim @0x10007000 +0x18 (CIA) readl=0x0100f84b ioread32be=0x4bf80001
shim @0x10007000 +0x20 (ADDR) readl=0x05400010 ioread32be=0x10004005
shim @0x10007000 +0x2c (ADDR) readl=0x05500010 ioread32be=0x10005005
shim @0x10007000 +0x38 (ADDR) readl=0x05700010 ioread32be=0x10007005
shim @0x10007000 +0x3c (EOT) readl=0x0f000000 ioread32be=0x0000000f
The BE column seems correct:
- chip id 0x6362 in CC_ID
- CIA entries with Broadcom vendor 0x4bf
- ADDR descriptors pointing back at the expected core bases
The readl() column is just the same words byte-swapped, which matches
what I observe at runtime: bcma_bus_scan() fail to scan with -88
The relevant call sites are:
- drivers/bcma/scan.c
bcma_erom_get_ent() -- readl() directly; this is the function
where bus scanning breaks immediately
bcma_scan_read32() -- readl() directly
- drivers/bcma/host_soc.c
all read*/write* ops use readb/readw/readl / writeb/writew/writel
I don't know how to disambinguate at runtime as scan.c reads the data
before the chip id is known, so a runtime quirk based on the chip id
is not workable.
Maybe if the endianness is known at bind time with a standard property
in the DT the bug can be fixed while leaving the default as is
Happy to test patches on the device, or i'll send an RFC myself if
you'd rather review some code.
Thanks,
Alessio Ferri
^ permalink raw reply
* Re: [PATCH 2/3] [v5 net-next] p54spi: convert to devicetree
From: Simon Horman @ 2026-05-12 9:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Netdev, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S . Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, krzk+dt, Linus Walleij, Paolo Abeni,
Rob Herring, Roger Quadros, Tony Lindgren, linux-wireless,
devicetree, linux-kernel, linux-arm-kernel,
open list:GPIO SUBSYSTEM, Linux-OMAP, Krzysztof Kozlowski
In-Reply-To: <edc4d6d6-7a43-442e-adb5-148e37402924@app.fastmail.com>
On Mon, May 11, 2026 at 09:45:18PM +0200, Arnd Bergmann wrote:
> On Mon, May 11, 2026, at 18:12, Simon Horman wrote:
> >
> > Simon says: As a pre-existing issue I don't think we need to be concerned
> > about this in the scope of this patch-set. But it may
> > be a potential for follow-up.
> >
> > This problem wasn't introduced by this patch, but I noticed a pre-existing
> > issue in the context here. Does the p54spi_spi_read() function perform an SPI
> > transfer using a stack-allocated buffer?
> >
> > Looking at p54spi_spi_read(), the addr variable is allocated on the stack and
> > passed as a transfer buffer to spi_sync(). The SPI framework maps transfer
> > buffers for DMA. Passing a stack-allocated buffer is illegal, particularly with
> > CONFIG_VMAP_STACK enabled, because stack memory resides in vmalloc space and
> > cannot be safely DMA-mapped.
> >
> > Could this cause memory corruption or a kernel panic during the transfer?
>
> I already commented on this earlier: This is indeed a theoretical
> bug, but it works in practice because DMA-capable SPI controllers
> tend to all use MMIO for short transfers instead of DMA.
>
> SPI is very fragile this way, and I do have some patches to improve
> that overall, but it seems out of scope for this one driver.
Thanks, I agree this is out of scope.
> >> -
> >> - gpio_direction_output(p54spi_gpio_power, 0);
> >> - gpio_direction_input(p54spi_gpio_irq);
> >> -
> >> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
> >> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
> >> - priv->spi);
> >> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
> >
> > Simon says: This one seems more concerning in the context of this patch-set.
> >
> > Is there missing validation for spi->irq before calling request_irq()?
> >
> > If the device tree node lacks an interrupts property, the SPI core may set
> > spi->irq to 0 or a negative error code.
> >
> > Passing this directly to request_irq() without validation can successfully
> > hijack a core system interrupt like the system timer on some architectures,
> > leading to system instability or deadlocks.
> >
> > Should there be a check like if (spi->irq <= 0) to fail the probe gracefully?
>
> I also commented on this: request_irq() already fails gracefully
> with -EINVAL when presented with an invalid IRQ. IRQ 0 is guaranteed
> to be invalid on any target that uses devicetree.
Thanks, and sorry for not seeing your earlier comment.
Or realising it is a false positive.
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Johannes Berg @ 2026-05-12 9:36 UTC (permalink / raw)
To: Thorsten Leemhuis, Ping-Ke Shih
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <02c073d8-d2c9-4faa-be51-9ba38247b24e@leemhuis.info>
On Tue, 2026-05-12 at 10:54 +0200, Thorsten Leemhuis wrote:
> > > You
> > > can cherry-pick or directly apply the fix to a pending branch (or even
> > > ask Linus to merge it directly from the list, but that is likely not
> > > worth it here) and git will normally later notice this and fully
> > > automatically handle everything when the fix comes in again during the
> > > next merge window.
> >
> > I know git can handle that, but is it an acceptable practice for single one
> > commit to appear twice?
>
> Depends on whom you ask. I'd say: It's kinda normal. It's best avoided
> if there is no need, but if there is a need (like here) it's fine. And
> some subsystems it even happens regularly iirc.
FWIW, it's generally frowned upon and actually uncommon enough that
linux-next actively warns about it [1] (or at least used to?), so I
wouldn't really say your description here is all that accurate.
[1] https://lore.kernel.org/lkml/?q=%22duplicate+patch+in+the%22
What does happen fairly frequently is the same immutable commit getting
merged through different branches, but that's a single commit, not the
same change being committed twice.
johannes
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Thorsten Leemhuis @ 2026-05-12 8:54 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <29a93dc3d9d24b3a809310694ffc5d34@realtek.com>
On 5/12/26 10:32, Ping-Ke Shih wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> wrote:
>> On 5/12/26 02:44, Ping-Ke Shih wrote:
>>> Thorsten Leemhuis <linux@leemhuis.info> wrote:
>>>> On 5/6/26 09:57, Ping-Ke Shih wrote:
>>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>>
>>>>>> Some devices malfunction when connected to a network with 40 MHz channel
>>>>>> width, because they don't support that.
>>>>>>
>>>>>> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
>>>>>> this (and some other capabilities) to the driver. Get this information
>>>>>> from the hardware and advertise 40 MHz support only when the hardware
>>>>>> can handle it. We assume the other chips can always handle it.
>>>>>>
>>>>>> RTL8710BU needs a different way to retrieve this information, which will
>>>>>> be implemented some other time.
>>>>>>
>>>>>> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>>>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>>>>
>>>> Thx for fixing this!
>>>>
>>>>> 1 patch(es) applied to rtw-next branch of rtw.git, thanks.
>>>>> ef771eabc79d wifi: rtl8xxxu: Detect the maximum supported channel width
>>>>> https://github.com/pkshih/rtw.git
>>>>
>>>> rtw-next sounds like it aims for the next merge window; and it seems the
>>>> fix hasn't even hit -next yet. This is slightly unfortunate, as this
>>>> afaics is a fix for a recent regression -- so it ideally should head
>>>> towards mainline by now[1], as Linus' the rule of thumb is to "generally
>>>> fix regressions "within a week", preferably before the next rc"[1].
>>>>
>>>> Or am I missing something? That might very well be the case, so do not
>>>> hesitate to tell me!
>>>
>>> As this patch applied to public rtw tree, and people who encountered the
>>> problem in bugzilla can work again. To prevent breaking the public tree,
>>> I'd keep it as was.
>> I'm not sure I understand this correctly.
>>
>> Do you mean something like "the fix is now in the rtw-next tree, so I
>> can't mainline it now, as this would break the rtw-next"? But why?
> Yes. (I meant rtw-next tree)
>
>> You
>> can cherry-pick or directly apply the fix to a pending branch (or even
>> ask Linus to merge it directly from the list, but that is likely not
>> worth it here) and git will normally later notice this and fully
>> automatically handle everything when the fix comes in again during the
>> next merge window.
>
> I know git can handle that, but is it an acceptable practice for single one
> commit to appear twice?
Depends on whom you ask. I'd say: It's kinda normal. It's best avoided
if there is no need, but if there is a need (like here) it's fine. And
some subsystems it even happens regularly iirc.
> As the reporter has fixed his problem, can we keep this commit as it was?
Well, it boils down to: we don't know how many others are affected that
are unable to bisect and/or report the problem. So usually it's best to
fix things like this for everyone.
Ciao, Thorsten
^ permalink raw reply
* Re: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Bitterblue Smith @ 2026-05-12 8:48 UTC (permalink / raw)
To: Devin Wittmayer, linux-wireless; +Cc: pkshih, johannes, linux-kernel
In-Reply-To: <20260512003559.44110-1-lucid_duck@justthetip.ca>
On 12/05/2026 03:35, Devin Wittmayer wrote:
> On Tue, 2026-05-12 at 01:27 +0300, Bitterblue Smith wrote:
>> Good, good. So how did you avoid the crash?
>
> If you mean the crash at
> https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/crash-2026-04-11
No, not that one.
> -- that was BE-gen DACK calibration and is unrelated to this
> USB 2-to-3 switch-mode patch. Four AX-gen adapters concurrent on
> one xHCI host complete switch-mode and RF calibration without
> DACK errors.
>
> Devin
^ permalink raw reply
* RE: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Ping-Ke Shih @ 2026-05-12 8:32 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <1cf071e9-5d3c-4d55-ac75-49eb4c461422@leemhuis.info>
Thorsten Leemhuis <regressions@leemhuis.info> wrote:
> On 5/12/26 02:44, Ping-Ke Shih wrote:
> > Thorsten Leemhuis <linux@leemhuis.info> wrote:
> >> On 5/6/26 09:57, Ping-Ke Shih wrote:
> >>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >>>
> >>>> Some devices malfunction when connected to a network with 40 MHz channel
> >>>> width, because they don't support that.
> >>>>
> >>>> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
> >>>> this (and some other capabilities) to the driver. Get this information
> >>>> from the hardware and advertise 40 MHz support only when the hardware
> >>>> can handle it. We assume the other chips can always handle it.
> >>>>
> >>>> RTL8710BU needs a different way to retrieve this information, which will
> >>>> be implemented some other time.
> >>>>
> >>>> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
> >>>> Cc: stable@vger.kernel.org
> >>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
> >>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >>>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
> >>
> >> Thx for fixing this!
> >>
> >>> 1 patch(es) applied to rtw-next branch of rtw.git, thanks.
> >>> ef771eabc79d wifi: rtl8xxxu: Detect the maximum supported channel width
> >>> https://github.com/pkshih/rtw.git
> >>
> >> rtw-next sounds like it aims for the next merge window; and it seems the
> >> fix hasn't even hit -next yet. This is slightly unfortunate, as this
> >> afaics is a fix for a recent regression -- so it ideally should head
> >> towards mainline by now[1], as Linus' the rule of thumb is to "generally
> >> fix regressions "within a week", preferably before the next rc"[1].
> >>
> >> Or am I missing something? That might very well be the case, so do not
> >> hesitate to tell me!
> >
> > As this patch applied to public rtw tree, and people who encountered the
> > problem in bugzilla can work again. To prevent breaking the public tree,
> > I'd keep it as was.
>
> I'm not sure I understand this correctly.
>
> Do you mean something like "the fix is now in the rtw-next tree, so I
> can't mainline it now, as this would break the rtw-next"? But why?
Yes. (I meant rtw-next tree)
> You
> can cherry-pick or directly apply the fix to a pending branch (or even
> ask Linus to merge it directly from the list, but that is likely not
> worth it here) and git will normally later notice this and fully
> automatically handle everything when the fix comes in again during the
> next merge window.
I know git can handle that, but is it an acceptable practice for single one
commit to appear twice?
As the reporter has fixed his problem, can we keep this commit as it was?
Ping-Ke
^ permalink raw reply
* [PATCH] wifi: ath11k: fix txpower in ap mode for 6 Ghz
From: Sebastian Gottschall @ 2026-05-12 8:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Sebastian Gottschall
there is an issue which has been discovered a while ago while testing
which killed txpower to 0dbm once scanning is triggered in AP mode
on QCN9074 based chipsets if 6 Ghz is in use.
ath11k_wmi_send_vdev_set_tpc_power must be set in AP mode in the same
way is it is for STA as it is implemented in ath12k and in the
qsdk version for ath11k.
this patch must be considered to be backported (i discovered that issue
already 2 years ago)
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
---
drivers/net/wireless/ath/ath11k/mac.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index a48b6bf1f29a..dc192152b2e8 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -3497,13 +3497,14 @@ static int ath11k_mac_config_obss_pd(struct ath11k *ar,
return 0;
}
-static bool ath11k_mac_supports_station_tpc(struct ath11k *ar,
+static bool ath11k_mac_supports_tpc(struct ath11k *ar,
struct ath11k_vif *arvif,
const struct cfg80211_chan_def *chandef)
{
return ath11k_wmi_supports_6ghz_cc_ext(ar) &&
test_bit(WMI_TLV_SERVICE_EXT_TPC_REG_SUPPORT, ar->ab->wmi_ab.svc_map) &&
- arvif->vdev_type == WMI_VDEV_TYPE_STA &&
+ (arvif->vdev_type == WMI_VDEV_TYPE_STA ||
+ arvif->vdev_type == WMI_VDEV_TYPE_AP) &&
arvif->vdev_subtype == WMI_VDEV_SUBTYPE_NONE &&
chandef->chan &&
chandef->chan->band == NL80211_BAND_6GHZ;
@@ -7647,8 +7648,8 @@ ath11k_mac_vdev_start_restart(struct ath11k_vif *arvif,
/* TODO: For now we only set TPC power here. However when
* channel changes, say CSA, it should be updated again.
*/
- if (ath11k_mac_supports_station_tpc(ar, arvif, chandef)) {
- ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, &arvif->chanctx);
+ if (ath11k_mac_supports_tpc(ar, arvif, chandef)) {
+ ath11k_mac_fill_reg_tpc_info(ar, arvif->vif, ctx);
ath11k_wmi_send_vdev_set_tpc_power(ar, arvif->vdev_id,
&arvif->reg_tpc_info);
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 2/2] staging: rtl8723bs: bound SUPP_RATES IE length in rtw_check_beacon_data
From: Dan Carpenter @ 2026-05-12 7:37 UTC (permalink / raw)
To: Shayaun Nejad
Cc: Greg Kroah-Hartman, linux-staging, linux-wireless, linux-kernel,
stable
In-Reply-To: <a56d8fa71dc6843e5096ce69d4c216c0ca99a7de.1778550157.git.snejad123@gmail.com>
On Mon, May 11, 2026 at 06:44:56PM -0700, Shayaun Nejad wrote:
> rtw_check_beacon_data() copies SUPP_RATES and EXT_SUPP_RATES IE
> payloads into a 16-byte support_rate[] buffer.
>
> The IE lengths are used directly, so oversized rate IEs can overflow the
> stack buffer.
>
> Clamp the supported rates copy and the combined extended supported rates
> copy to NDIS_802_11_LENGTH_RATES_EX.
>
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shayaun Nejad <snejad123@gmail.com>
> ---
> drivers/staging/rtl8723bs/core/rtw_ap.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> index 4b40124110..363ecb02b5 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> @@ -873,6 +873,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 *pbuf, int len)
> &ie_len,
> (pbss_network->ie_length - _BEACON_IE_OFFSET_));
> if (p) {
> + ie_len = min_t(uint, ie_len, NDIS_802_11_LENGTH_RATES_EX);
These days we would use umin()
> memcpy(support_rate, p + 2, ie_len);
> support_rate_num = ie_len;
support_rate_num is set here. We know from the min_t() that it's less
<= NDIS_802_11_LENGTH_RATES_EX.
> }
> @@ -882,8 +883,11 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 *pbuf, int len)
> WLAN_EID_EXT_SUPP_RATES,
> &ie_len,
> pbss_network->ie_length - _BEACON_IE_OFFSET_);
> - if (p)
> + if (p && support_rate_num < NDIS_802_11_LENGTH_RATES_EX) {
We know that support_rate_num <= NDIS_802_11_LENGTH_RATES_EX. Allowing
== NDIS_802_11_LENGTH_RATES_EX is okay because memcpy() of zero bytes is
a no-op.
> + ie_len = min_t(uint, ie_len,
> + NDIS_802_11_LENGTH_RATES_EX - support_rate_num);
Use umin() here too.
Otherwise the patch is fine.
regards,
dan carpenter
> memcpy(support_rate + support_rate_num, p + 2, ie_len);
> + }
>
> network_type = rtw_check_network_type(support_rate, channel);
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Thorsten Leemhuis @ 2026-05-12 7:17 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <f26992e669744e6f87084e017f897275@realtek.com>
On 5/12/26 02:44, Ping-Ke Shih wrote:
> Thorsten Leemhuis <linux@leemhuis.info> wrote:
>> On 5/6/26 09:57, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>
>>>> Some devices malfunction when connected to a network with 40 MHz channel
>>>> width, because they don't support that.
>>>>
>>>> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
>>>> this (and some other capabilities) to the driver. Get this information
>>>> from the hardware and advertise 40 MHz support only when the hardware
>>>> can handle it. We assume the other chips can always handle it.
>>>>
>>>> RTL8710BU needs a different way to retrieve this information, which will
>>>> be implemented some other time.
>>>>
>>>> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
>>>> Cc: stable@vger.kernel.org
>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>>
>> Thx for fixing this!
>>
>>> 1 patch(es) applied to rtw-next branch of rtw.git, thanks.
>>> ef771eabc79d wifi: rtl8xxxu: Detect the maximum supported channel width
>>> https://github.com/pkshih/rtw.git
>>
>> rtw-next sounds like it aims for the next merge window; and it seems the
>> fix hasn't even hit -next yet. This is slightly unfortunate, as this
>> afaics is a fix for a recent regression -- so it ideally should head
>> towards mainline by now[1], as Linus' the rule of thumb is to "generally
>> fix regressions "within a week", preferably before the next rc"[1].
>>
>> Or am I missing something? That might very well be the case, so do not
>> hesitate to tell me!
>
> As this patch applied to public rtw tree, and people who encountered the
> problem in bugzilla can work again. To prevent breaking the public tree,
> I'd keep it as was.
I'm not sure I understand this correctly.
Do you mean something like "the fix is now in the rtw-next tree, so I
can't mainline it now, as this would break the rtw-next"? But why? You
can cherry-pick or directly apply the fix to a pending branch (or even
ask Linus to merge it directly from the list, but that is likely not
worth it here) and git will normally later notice this and fully
automatically handle everything when the fix comes in again during the
next merge window.
Or did I misinterpret what you meant?
Ciao, Thorsten
^ 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