* RE: [PATCH v2 3/3] wifi: iwlwifi: nvm: replace use of system_wq with system_percpu_wq
From: Korenblit, Miriam Rachel @ 2026-02-09 7:58 UTC (permalink / raw)
To: Marco Crivellari, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <20251120100850.66192-4-marco.crivellari@suse.com>
> -----Original Message-----
> From: Marco Crivellari <marco.crivellari@suse.com>
> Sent: Thursday, November 20, 2025 12:09 PM
> To: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Tejun Heo <tj@kernel.org>; Lai Jiangshan <jiangshanlai@gmail.com>; Frederic
> Weisbecker <frederic@kernel.org>; Sebastian Andrzej Siewior
> <bigeasy@linutronix.de>; Marco Crivellari <marco.crivellari@suse.com>; Michal
> Hocko <mhocko@suse.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Johannes Berg
> <johannes@sipsolutions.net>
> Subject: [PATCH v2 3/3] wifi: iwlwifi: nvm: replace use of system_wq with
Please change nvm->mvm.
Otherwise looks good to me
> system_percpu_wq
>
> This patch continues the effort to refactor workqueue APIs, which has begun with
> the changes introducing new workqueues and a new alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and
> system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
>
> Before that to happen after a careful review and conversion of each individual
> case, workqueue users must be converted to the better named new workqueues
> with no intended behaviour changes:
>
> system_wq -> system_percpu_wq
> system_unbound_wq -> system_dfl_wq
>
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
> 2.51.1
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: fix backoff fields and max_power calculation
From: Ryder Lee @ 2026-02-09 7:48 UTC (permalink / raw)
To: robh@kernel.org, sven@narfation.org
Cc: linux-wireless@vger.kernel.org, nbd@nbd.name,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), saravanak@kernel.org
In-Reply-To: <7906220.EvYhyI6sBW@ripper>
On Mon, 2026-02-02 at 09:14 +0100, Sven Eckelmann wrote:
> On Wednesday, 28 January 2026 00:55:57 CET Ryder Lee wrote:
> > + case MT76_SKU_BACKOFF:
> > + backoff_chain_idx += 1;
> > + fallthrough;
> > + case MT76_SKU_BACKOFF_BF_OFFSET:
> > + delta = mt76_tx_power_path_delta(n_chains);
> > + backoff_n_chains =
> > mt76_backoff_n_chains(dev, backoff_chain_idx);
> > + backoff_delta =
> > mt76_tx_power_path_delta(backoff_n_chains);
> > + break;
> > + default:
>
> Please double check whether the "case"s for
> MT76_SKU_BACKOFF_BF_OFFSET and
> MT76_SKU_BACKOFF should actually be swapped. I think I've originally
> introduced this mistake when trying to demonstrate different ways to
> write the
> switch block.
>
>
> > + /* For connac2 devices,
> > + * - paths-ru = RU26, RU52, RU106, BW20, BW40,
> > BW80, BW160
> > + * - paths-ru-bf = RU26, RU52, RU106, BW20, BW40,
> > BW80, BW160
> > + * Only the first three entries use 1T1ss and do
> > not need index
> > + * adjustment; the remaining four require index
> > offset.
> > + */
>
>
> Hm, I doubt that anyone can understand this (same for the commit
> message).
> You basically just showed a list of two equal "array"s.
>
> Actually important here is that, RU26, RU52, RU106, ... stand here
> for 10
> different values:
>
> 1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss, 4T2ss, 3T3ss, 4T3ss, 4T4ss
>
> For paths-ru-bf, also 10 values are stored in the DT for each of
> these
> (RU26, ..., BW160) - but only the non-1T1ss are relevant for this
> calculation for BW20, ..., BW160.
>
> These 1T1ss beamforming values for BW20, ..., BW160 were (if I
> understand it
> correctly) removed for connac3.
>
> If you introduce some change in the DT interpretation, then you must
> also
> inform the DT maintainers (Rob Herring <robh@kernel.org>,
> Saravana Kannan <saravanak@kernel.org>, devicetree@vger.kernel.org)
> while
> updatingDocumentation/devicetree/bindings/net/wireless/mediatek%2Cmt7
> 6.yaml.
> The latter is currently still expecting 1 ("rates multiplier") + 10
> values
> (limits). And DTs with only 1 + 9 values per rate would therefore
> fail to be
> validated.
>
> At the moment, your connac3 code is basically conflicting with the
> devicetree
> documentation. I will leave it to the experts to figure out if the
> devicetree
> should have two different interpretations for the same property or
> whether
> the property should be the same and the code must handle the
> differences
> before sending these values to the HW.
>
> Regards,
> Sven
>
I think the DTS format for connac3 is also 1 multiplier plus 10 values,
not 1+9. The key should be:
For beamforming tables:
- In connac2, beamforming entries for BW20~BW160 and OFDM do not
include 1T1ss.
- In connac3, beamforming entries for BW20~BW160 and RU include 1T1ss,
but OFDM beamforming does not include 1T1ss.
Non-beamforming and RU entries for both connac2 and connac3 include
1T1ss.
I will add this explanation to patch v3, and I have already fixed the
copy-paste error above.
Ryder
^ permalink raw reply
* Re: miriam.rachel.korenblit@intel.com
From: Emmanuel Grumbach @ 2026-02-09 7:27 UTC (permalink / raw)
To: Maxim Schoening; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <wLZVXoPkLGec1OnYaA-mWI-GD0IzTZFMVJBP-E1d6q2xsBKubMhd67js94mBMze_5NuuYNQ3eeezFU-lddpFXqD4-cRhIOuCVXdWY4L-Fao=@protonmail.com>
On Sun, Feb 8, 2026 at 11:19 PM Maxim Schoening
<maxim.schoening@protonmail.com> wrote:
>
> Hi,
>
> The iwlwifi-bz-b0-hr-b0 firmware has not been updated past version 98 (core98-161, October 2025), but the 6.18 kernel's iwlwifi driver has raised ucode_api_min above 98 for this device class, resulting in complete Wi-Fi failure.
>
> On 6.17.9, the driver falls back to 98 successfully:
>
> iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-100.ucode failed with error -2
> iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-99.ucode failed with error -2
> iwlwifi 0000:00:14.3: loaded firmware version 98.d661c37c.0 bz-b0-hr-b0-98.ucode op_mode iwlmvm
>
> On 6.18.7, the fallback no longer works and Wi-Fi is completely broken.
>
> Neither iwlwifi-bz-b0-hr-b0-99.ucode nor -100.ucode exist in mainline linux-firmware or the iwlwifi for-upstream branch. Other Bz variants have been actively updated during this period:
>
> bz-b0-gf-a0: updated to 100 bz-b0-fm-c0: updated to c102 bz-b0-hr-b0: stuck at 98 since October 2025
>
> The most recent for-upstream commit (9a9285ce, 2026-01-15, "iwlwifi: add Bz/Sc FW for core102-56 release") adds firmware for Bz/Fm and gl but not Bz/Hr.
>
> This looks like a coordination gap: ucode_api_min was bumped without matching firmware being released for all affected sub-variants.
>
>
> Affected hardware:
> [17.350374] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX203
> Device:
> Xiaomi Redmi Book Pro 2025 PCI ID: 8086:7740 PCI path: 0000:00:14.3 Variant: bz-b0-hr-b0 (Blazer CNVi + Harrison Peak radio)
> Working: 6.17.9-76061709-generic
> Broken: 6.18.7-76061807-generic
>
> This is the same device class previously affected by LP #2102029, which was resolved when bz-b0-hr-b0-96.ucode was added in the core93-123 release.
>
> Could the Bz/Hr firmware be brought up to match the other Bz variants, or alternatively, could the ucode_api_min for bz-b0-hr-b0 be reverted to 98 until the firmware is available?
>
I replied in the bug you raised here:
https://bugzilla.kernel.org/show_bug.cgi?id=221063
>
> Best,
> Maxim
>
^ permalink raw reply
* RE: [PATCH v2 iwlwifi-next] wifi: iwlwifi: Add missing firmware info for bz-b0-* models
From: Korenblit, Miriam Rachel @ 2026-02-09 7:19 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20251118121251.149922-1-tiwai@suse.de>
> -----Original Message-----
> From: Takashi Iwai <tiwai@suse.de>
> Sent: Tuesday, November 18, 2025 2:13 PM
> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>
> Cc: linux-wireless@vger.kernel.org
> Subject: [PATCH v2 iwlwifi-next] wifi: iwlwifi: Add missing firmware info for bz-
> b0-* models
>
> The module firmware info is missing for iwlwifi-bz-b0-* models, which results in
> the non-working WiFi on some installers or images.
>
> Add the entries for iwlwifi-bz-b0-fm-c0, iwlwifi-bz-b0-gf-a0 and iwlwifi-bz-b0-hr-
> b0.
>
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1252084
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1: https://lore.kernel.org/20251015141307.25305-1-tiwai@suse.de
> v1->v2: rebased, apply the change to rf-fm.c
>
> drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c
> b/drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c
> index ad2536f53084..b0e8b4af6891 100644
> --- a/drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c
> +++ b/drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c
> @@ -8,6 +8,9 @@
> #define IWL_BZ_A_FM_B_FW_PRE "iwlwifi-bz-a0-fm-b0"
> #define IWL_BZ_A_FM_C_FW_PRE "iwlwifi-bz-a0-fm-c0"
> #define IWL_BZ_A_FM4_B_FW_PRE "iwlwifi-bz-a0-fm4-b0"
You can actually replace the bz-b0 with the bz-a0, as they are not released
> +#define IWL_BZ_B_FM_C_FW_PRE "iwlwifi-bz-b0-fm-c0"
> +#define IWL_BZ_B_GF_A_FW_PRE "iwlwifi-bz-b0-gf-a0"
This belongs to rf-gf.c
> +#define IWL_BZ_B_HR_B_FW_PRE "iwlwifi-bz-b0-hr-b0"
This belongs to rf-hr.c
> #define IWL_GL_B_FM_B_FW_PRE "iwlwifi-gl-b0-fm-b0"
> #define IWL_GL_C_FM_C_FW_PRE "iwlwifi-gl-c0-fm-c0"
>
> @@ -60,5 +63,8 @@ const char iwl_be401_name[] = "Intel(R) Wi-Fi 7 BE401
> 320MHz"; IWL_CORE_FW(IWL_BZ_A_FM_B_FW_PRE,
> IWL_BZ_UCODE_CORE_MAX); IWL_CORE_FW(IWL_BZ_A_FM_C_FW_PRE,
> IWL_BZ_UCODE_CORE_MAX); IWL_CORE_FW(IWL_BZ_A_FM4_B_FW_PRE,
> IWL_BZ_UCODE_CORE_MAX);
> +IWL_CORE_FW(IWL_BZ_B_FM_C_FW_PRE, IWL_BZ_UCODE_CORE_MAX);
> +IWL_CORE_FW(IWL_BZ_B_GF_A_FW_PRE, IWL_BZ_UCODE_CORE_MAX);
> +IWL_CORE_FW(IWL_BZ_B_HR_B_FW_PRE, IWL_BZ_UCODE_CORE_MAX);
> IWL_CORE_FW(IWL_GL_B_FM_B_FW_PRE, IWL_BZ_UCODE_CORE_MAX);
> IWL_CORE_FW(IWL_GL_C_FM_C_FW_PRE, IWL_BZ_UCODE_CORE_MAX);
> --
> 2.51.1
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: Fix legacy rate mapping for monitor mode capture
From: Thiraviyam Mariyappan @ 2026-02-09 5:49 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, P Praneesh, Thiraviyam Mariyappan
From: P Praneesh <praneesh.p@oss.qualcomm.com>
The current implementation incorrectly reports legacy CCK and OFDM rates
in monitor mode radiotap headers. The rate field displays wrong values,
for example showing 11 Mbps when the actual rate is 1 Mbps. This occurs
because the HAL layer uses a unified enum for both CCK and OFDM rates
without distinguishing between long/short preamble variants and proper
rate mapping to hardware rate indices.
The root cause is threefold:
1. The hal_rx_legacy_rate enum conflates CCK and OFDM rates into a
single enumeration, making it impossible to differentiate between
802.11b CCK rates (with long/short preamble variants) and 802.11a/g
OFDM rates.
2. The L-SIG-B parsing function maps hardware rate values to the wrong
enum values. For CCK rates, it incorrectly combines long and short
preamble cases (e.g., cases 2 and 5 both map to 2 Mbps), losing
preamble information critical for proper rate identification.
3. The mac layer's rate-to-index conversion function does not properly
handle the precedence between long preamble, short preamble, and
OFDM rates when matching hardware rate values.
Split the hal_rx_legacy_rate enum into two separate enumerations:
hal_rx_legacy_rate for CCK rates with explicit long preamble (LP) and
short preamble (SP) variants, and hal_rx_legacy_rates_ofdm for OFDM
rates. This separation allows proper identification of rate types and
preamble modes.
Introduce a new mapping ath12k_wifi7_hal_mon_map_legacy_rate_to_hw_rate()
that converts HAL CCK rate enums to hardware rate indices defined in
ath12k_hw_rate_cck. This ensures the rate field in ppdu_info contains
the correct hardware rate index that matches the mac layer's expectations.
Update the L-SIG-B parsing to map each hardware rate value (1-7) to its
corresponding CCK rate enum with proper preamble designation:
- Cases 1-4: Long preamble (1, 2, 5.5, 11 Mbps)
- Cases 5-7: Short preamble (2, 5.5, 11 Mbps)
Update the L-SIG-A parsing to use the new OFDM-specific enum values,
maintaining the existing rate mapping for 802.11a/g OFDM rates.
Refactor the mac layer's ath12k_mac_hw_rate_to_idx() function to
implement proper matching precedence:
1. First match OFDM rates using the IEEE80211_RATE_MANDATORY_A flag
2. Then match CCK short preamble rates
3. Finally match CCK long preamble rates as fallback
Add helper macros ATH12K_MAC_RATE_A_M and ATH12K_MAC_RATE_B to improve
readability of the rate table initialization and ensure the mandatory
flag is set for OFDM rates.
This fix ensures monitor mode captures display accurate rate information
in the radiotap header, correctly distinguishing between 1 Mbps and
11 Mbps, and properly identifying preamble types for CCK rates.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com>
Signed-off-by: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/hal.h | 31 +++++---
drivers/net/wireless/ath/ath12k/mac.c | 51 +++++++------
.../net/wireless/ath/ath12k/wifi7/dp_mon.c | 76 +++++++++++++++----
3 files changed, 108 insertions(+), 50 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/hal.h b/drivers/net/wireless/ath/ath12k/hal.h
index 43e3880f8257..bf4f7dbae866 100644
--- a/drivers/net/wireless/ath/ath12k/hal.h
+++ b/drivers/net/wireless/ath/ath12k/hal.h
@@ -268,21 +268,28 @@ enum hal_rx_reception_type {
};
enum hal_rx_legacy_rate {
- HAL_RX_LEGACY_RATE_1_MBPS,
- HAL_RX_LEGACY_RATE_2_MBPS,
- HAL_RX_LEGACY_RATE_5_5_MBPS,
- HAL_RX_LEGACY_RATE_6_MBPS,
- HAL_RX_LEGACY_RATE_9_MBPS,
- HAL_RX_LEGACY_RATE_11_MBPS,
- HAL_RX_LEGACY_RATE_12_MBPS,
- HAL_RX_LEGACY_RATE_18_MBPS,
- HAL_RX_LEGACY_RATE_24_MBPS,
- HAL_RX_LEGACY_RATE_36_MBPS,
- HAL_RX_LEGACY_RATE_48_MBPS,
- HAL_RX_LEGACY_RATE_54_MBPS,
+ HAL_RX_LEGACY_RATE_LP_1_MBPS,
+ HAL_RX_LEGACY_RATE_LP_2_MBPS,
+ HAL_RX_LEGACY_RATE_LP_5_5_MBPS,
+ HAL_RX_LEGACY_RATE_LP_11_MBPS,
+ HAL_RX_LEGACY_RATE_SP_2_MBPS,
+ HAL_RX_LEGACY_RATE_SP_5_5_MBPS,
+ HAL_RX_LEGACY_RATE_SP_11_MBPS,
HAL_RX_LEGACY_RATE_INVALID,
};
+enum hal_rx_legacy_rates_ofdm {
+ HAL_RX_LEGACY_RATE_OFDM_48_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_24_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_12_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_6_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_54_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_36_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_18_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_9_MBPS,
+ HAL_RX_LEGACY_RATE_OFDM_INVALID,
+};
+
enum hal_ring_type {
HAL_REO_DST,
HAL_REO_EXCEPTION,
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 6c534f0d59ce..035937dde5c6 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -164,30 +164,31 @@ static const struct ieee80211_channel ath12k_6ghz_channels[] = {
CHAN6G(233, 7115, 0),
};
+#define ATH12K_MAC_RATE_A_M(bps, code) \
+ { .bitrate = (bps), .hw_value = (code),\
+ .flags = IEEE80211_RATE_MANDATORY_A }
+
+#define ATH12K_MAC_RATE_B(bps, code, code_short) \
+ { .bitrate = (bps), .hw_value = (code), .hw_value_short = (code_short),\
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE }
+
static struct ieee80211_rate ath12k_legacy_rates[] = {
{ .bitrate = 10,
.hw_value = ATH12K_HW_RATE_CCK_LP_1M },
- { .bitrate = 20,
- .hw_value = ATH12K_HW_RATE_CCK_LP_2M,
- .hw_value_short = ATH12K_HW_RATE_CCK_SP_2M,
- .flags = IEEE80211_RATE_SHORT_PREAMBLE },
- { .bitrate = 55,
- .hw_value = ATH12K_HW_RATE_CCK_LP_5_5M,
- .hw_value_short = ATH12K_HW_RATE_CCK_SP_5_5M,
- .flags = IEEE80211_RATE_SHORT_PREAMBLE },
- { .bitrate = 110,
- .hw_value = ATH12K_HW_RATE_CCK_LP_11M,
- .hw_value_short = ATH12K_HW_RATE_CCK_SP_11M,
- .flags = IEEE80211_RATE_SHORT_PREAMBLE },
-
- { .bitrate = 60, .hw_value = ATH12K_HW_RATE_OFDM_6M },
- { .bitrate = 90, .hw_value = ATH12K_HW_RATE_OFDM_9M },
- { .bitrate = 120, .hw_value = ATH12K_HW_RATE_OFDM_12M },
- { .bitrate = 180, .hw_value = ATH12K_HW_RATE_OFDM_18M },
- { .bitrate = 240, .hw_value = ATH12K_HW_RATE_OFDM_24M },
- { .bitrate = 360, .hw_value = ATH12K_HW_RATE_OFDM_36M },
- { .bitrate = 480, .hw_value = ATH12K_HW_RATE_OFDM_48M },
- { .bitrate = 540, .hw_value = ATH12K_HW_RATE_OFDM_54M },
+ ATH12K_MAC_RATE_B(20, ATH12K_HW_RATE_CCK_LP_2M,
+ ATH12K_HW_RATE_CCK_SP_2M),
+ ATH12K_MAC_RATE_B(55, ATH12K_HW_RATE_CCK_LP_5_5M,
+ ATH12K_HW_RATE_CCK_SP_5_5M),
+ ATH12K_MAC_RATE_B(110, ATH12K_HW_RATE_CCK_LP_11M,
+ ATH12K_HW_RATE_CCK_SP_11M),
+ ATH12K_MAC_RATE_A_M(60, ATH12K_HW_RATE_OFDM_6M),
+ ATH12K_MAC_RATE_A_M(90, ATH12K_HW_RATE_OFDM_9M),
+ ATH12K_MAC_RATE_A_M(120, ATH12K_HW_RATE_OFDM_12M),
+ ATH12K_MAC_RATE_A_M(180, ATH12K_HW_RATE_OFDM_18M),
+ ATH12K_MAC_RATE_A_M(240, ATH12K_HW_RATE_OFDM_24M),
+ ATH12K_MAC_RATE_A_M(360, ATH12K_HW_RATE_OFDM_36M),
+ ATH12K_MAC_RATE_A_M(480, ATH12K_HW_RATE_OFDM_48M),
+ ATH12K_MAC_RATE_A_M(540, ATH12K_HW_RATE_OFDM_54M),
};
static const int
@@ -732,11 +733,17 @@ u8 ath12k_mac_hw_rate_to_idx(const struct ieee80211_supported_band *sband,
if (ath12k_mac_bitrate_is_cck(rate->bitrate) != cck)
continue;
- if (rate->hw_value == hw_rate)
+ /* To handle 802.11a PPDU type */
+ if ((!cck) && (rate->hw_value == hw_rate) &&
+ (rate->flags & IEEE80211_RATE_MANDATORY_A))
return i;
+ /* To handle 802.11b short PPDU type */
else if (rate->flags & IEEE80211_RATE_SHORT_PREAMBLE &&
rate->hw_value_short == hw_rate)
return i;
+ /* To handle 802.11b long PPDU type */
+ else if (rate->hw_value == hw_rate)
+ return i;
}
return 0;
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c b/drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c
index bd741532b7dc..074df2ab6bbf 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c
@@ -405,6 +405,42 @@ ath12k_wifi7_dp_mon_hal_rx_parse_user_info(const struct hal_receive_user_info *r
}
}
+static __always_inline u8
+ath12k_wifi7_hal_mon_map_legacy_rate_to_hw_rate(u8 rate)
+{
+ u8 ath12k_rate;
+
+ /* Map hal_rx_legacy_rate to ath12k_hw_rate_cck */
+ switch (rate) {
+ case HAL_RX_LEGACY_RATE_LP_1_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_LP_1M;
+ break;
+ case HAL_RX_LEGACY_RATE_LP_2_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_LP_2M;
+ break;
+ case HAL_RX_LEGACY_RATE_LP_5_5_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_LP_5_5M;
+ break;
+ case HAL_RX_LEGACY_RATE_LP_11_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_LP_11M;
+ break;
+ case HAL_RX_LEGACY_RATE_SP_2_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_SP_2M;
+ break;
+ case HAL_RX_LEGACY_RATE_SP_5_5_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_SP_5_5M;
+ break;
+ case HAL_RX_LEGACY_RATE_SP_11_MBPS:
+ ath12k_rate = ATH12K_HW_RATE_CCK_SP_11M;
+ break;
+ default:
+ ath12k_rate = rate;
+ break;
+ }
+
+ return ath12k_rate;
+}
+
static void
ath12k_wifi7_dp_mon_parse_l_sig_b(const struct hal_rx_lsig_b_info *lsigb,
struct hal_rx_mon_ppdu_info *ppdu_info)
@@ -415,25 +451,32 @@ ath12k_wifi7_dp_mon_parse_l_sig_b(const struct hal_rx_lsig_b_info *lsigb,
rate = u32_get_bits(info0, HAL_RX_LSIG_B_INFO_INFO0_RATE);
switch (rate) {
case 1:
- rate = HAL_RX_LEGACY_RATE_1_MBPS;
+ rate = HAL_RX_LEGACY_RATE_LP_1_MBPS;
break;
case 2:
- case 5:
- rate = HAL_RX_LEGACY_RATE_2_MBPS;
+ rate = HAL_RX_LEGACY_RATE_LP_2_MBPS;
break;
case 3:
- case 6:
- rate = HAL_RX_LEGACY_RATE_5_5_MBPS;
+ rate = HAL_RX_LEGACY_RATE_LP_5_5_MBPS;
break;
case 4:
+ rate = HAL_RX_LEGACY_RATE_LP_11_MBPS;
+ break;
+ case 5:
+ rate = HAL_RX_LEGACY_RATE_SP_2_MBPS;
+ break;
+ case 6:
+ rate = HAL_RX_LEGACY_RATE_SP_5_5_MBPS;
+ break;
case 7:
- rate = HAL_RX_LEGACY_RATE_11_MBPS;
+ rate = HAL_RX_LEGACY_RATE_SP_11_MBPS;
break;
default:
rate = HAL_RX_LEGACY_RATE_INVALID;
+ break;
}
- ppdu_info->rate = rate;
+ ppdu_info->rate = ath12k_wifi7_hal_mon_map_legacy_rate_to_hw_rate(rate);
ppdu_info->cck_flag = 1;
}
@@ -447,31 +490,32 @@ ath12k_wifi7_dp_mon_parse_l_sig_a(const struct hal_rx_lsig_a_info *lsiga,
rate = u32_get_bits(info0, HAL_RX_LSIG_A_INFO_INFO0_RATE);
switch (rate) {
case 8:
- rate = HAL_RX_LEGACY_RATE_48_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_48_MBPS;
break;
case 9:
- rate = HAL_RX_LEGACY_RATE_24_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_24_MBPS;
break;
case 10:
- rate = HAL_RX_LEGACY_RATE_12_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_12_MBPS;
break;
case 11:
- rate = HAL_RX_LEGACY_RATE_6_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_6_MBPS;
break;
case 12:
- rate = HAL_RX_LEGACY_RATE_54_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_54_MBPS;
break;
case 13:
- rate = HAL_RX_LEGACY_RATE_36_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_36_MBPS;
break;
case 14:
- rate = HAL_RX_LEGACY_RATE_18_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_18_MBPS;
break;
case 15:
- rate = HAL_RX_LEGACY_RATE_9_MBPS;
+ rate = HAL_RX_LEGACY_RATE_OFDM_9_MBPS;
break;
default:
- rate = HAL_RX_LEGACY_RATE_INVALID;
+ rate = HAL_RX_LEGACY_RATE_OFDM_INVALID;
+ break;
}
ppdu_info->rate = rate;
base-commit: 2c1ba9c2adf0fda96eaaebd8799268a7506a8fc9
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next 4/4] wifi: ath12k: sanitize invalid MCS metadata in monitor rx path
From: m.limarencko @ 2026-02-09 3:02 UTC (permalink / raw)
To: jjohnson; +Cc: linux-wireless, ath12k, linux-kernel, Mikhail Limarenko
In-Reply-To: <20260209030243.1530075-1-m.limarencko@yandex.ru>
From: Mikhail Limarenko <m.limarencko@yandex.ru>
Apply the same invalid-MCS hardening in monitor path status
conversion to keep metadata handling consistent in both data and
monitor pipelines.
Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
---
drivers/net/wireless/ath/ath12k/dp_mon.c | 38 ++++++++++++++----------
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/dp_mon.c b/drivers/net/wireless/ath/ath12k/dp_mon.c
index 009c495..6e894ef 100644
--- a/drivers/net/wireless/ath/ath12k/dp_mon.c
+++ b/drivers/net/wireless/ath/ath12k/dp_mon.c
@@ -1922,9 +1922,11 @@ ath12k_dp_mon_fill_rx_rate(struct ath12k *ar,
case RX_MSDU_START_PKT_TYPE_11N:
rx_status->encoding = RX_ENC_HT;
if (rate_mcs > ATH12K_HT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in HT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid HT mcs %u in monitor path, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
rx_status->rate_idx = rate_mcs + (8 * (nss - 1));
@@ -1933,35 +1935,41 @@ ath12k_dp_mon_fill_rx_rate(struct ath12k *ar,
break;
case RX_MSDU_START_PKT_TYPE_11AC:
rx_status->encoding = RX_ENC_VHT;
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH12K_VHT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in VHT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid VHT mcs %u in monitor path, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
+ rx_status->rate_idx = rate_mcs;
if (sgi)
rx_status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
break;
case RX_MSDU_START_PKT_TYPE_11AX:
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH12K_HE_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in HE mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid HE mcs %u in monitor path, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
+ rx_status->rate_idx = rate_mcs;
rx_status->encoding = RX_ENC_HE;
rx_status->he_gi = ath12k_he_gi_to_nl80211_he_gi(sgi);
break;
case RX_MSDU_START_PKT_TYPE_11BE:
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH12K_EHT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in EHT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid EHT mcs %u in monitor path, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
+ rx_status->rate_idx = rate_mcs;
rx_status->encoding = RX_ENC_EHT;
rx_status->he_gi = ath12k_he_gi_to_nl80211_he_gi(sgi);
break;
--
2.47.3
^ permalink raw reply related
* [PATCH ath-next 3/4] wifi: ath12k: sanitize invalid MCS metadata in rx path
From: m.limarencko @ 2026-02-09 3:02 UTC (permalink / raw)
To: jjohnson; +Cc: linux-wireless, ath12k, linux-kernel, Mikhail Limarenko
In-Reply-To: <20260209030243.1530075-1-m.limarencko@yandex.ru>
From: Mikhail Limarenko <m.limarencko@yandex.ru>
Malformed or unsupported rate metadata from firmware can carry
invalid MCS values into mac80211 status handling.
This was observed with HE MCS=12 and coincided with
ieee80211_rx_list warnings.
When MCS is out of range, fall back to legacy metadata and use
ratelimited diagnostics.
Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
---
drivers/net/wireless/ath/ath12k/dp_rx.c | 39 +++++++++++++++----------
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c
index 99d29ed..f0c56a9 100644
--- a/drivers/net/wireless/ath/ath12k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath12k/dp_rx.c
@@ -2534,9 +2534,11 @@ static void ath12k_dp_rx_h_rate(struct ath12k *ar, struct ath12k_dp_rx_info *rx_
case RX_MSDU_START_PKT_TYPE_11N:
rx_status->encoding = RX_ENC_HT;
if (rate_mcs > ATH12K_HT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in HT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid HT mcs %u, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
rx_status->rate_idx = rate_mcs + (8 * (nss - 1));
@@ -2546,42 +2548,47 @@ static void ath12k_dp_rx_h_rate(struct ath12k *ar, struct ath12k_dp_rx_info *rx_
break;
case RX_MSDU_START_PKT_TYPE_11AC:
rx_status->encoding = RX_ENC_VHT;
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH12K_VHT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in VHT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid VHT mcs %u, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
+ rx_status->rate_idx = rate_mcs;
rx_status->nss = nss;
if (sgi)
rx_status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
rx_status->bw = ath12k_mac_bw_to_mac80211_bw(bw);
break;
case RX_MSDU_START_PKT_TYPE_11AX:
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH12K_HE_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in HE mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid HE mcs %u, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
rx_status->encoding = RX_ENC_HE;
+ rx_status->rate_idx = rate_mcs;
rx_status->nss = nss;
rx_status->he_gi = ath12k_he_gi_to_nl80211_he_gi(sgi);
rx_status->bw = ath12k_mac_bw_to_mac80211_bw(bw);
break;
case RX_MSDU_START_PKT_TYPE_11BE:
- rx_status->rate_idx = rate_mcs;
-
if (rate_mcs > ATH12K_EHT_MCS_MAX) {
- ath12k_warn(ar->ab,
- "Received with invalid mcs in EHT mode %d\n",
- rate_mcs);
+ dev_warn_ratelimited(ar->ab->dev,
+ "ath12k: invalid EHT mcs %u, forcing legacy rate metadata\n",
+ rate_mcs);
+ rx_status->encoding = RX_ENC_LEGACY;
+ rx_status->rate_idx = 0;
break;
}
rx_status->encoding = RX_ENC_EHT;
+ rx_status->rate_idx = rate_mcs;
rx_status->nss = nss;
rx_status->eht.gi = ath12k_mac_eht_gi_to_nl80211_eht_gi(sgi);
rx_status->bw = ath12k_mac_bw_to_mac80211_bw(bw);
--
2.47.3
^ permalink raw reply related
* [PATCH ath-next 2/4] wifi: ath12k: avoid long fw_stats waits on vdev stats hot path
From: m.limarencko @ 2026-02-09 3:02 UTC (permalink / raw)
To: jjohnson; +Cc: linux-wireless, ath12k, linux-kernel, Mikhail Limarenko
In-Reply-To: <20260209030243.1530075-1-m.limarencko@yandex.ru>
From: Mikhail Limarenko <m.limarencko@yandex.ru>
Station info requests can trigger frequent VDEV stat pulls from
user space (iw/NM polling).
On affected firmware, waiting 3 seconds for fw_stats_done causes
repeated stalls and visible hitches.
Use a short timeout for VDEV_STAT requests and skip unnecessary
waits for stats types that do not need completion
synchronization.
Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
---
drivers/net/wireless/ath/ath12k/mac.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 095b49a..1b550e9 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -4829,6 +4829,7 @@ int ath12k_mac_get_fw_stats(struct ath12k *ar,
{
struct ath12k_base *ab = ar->ab;
struct ath12k_hw *ah = ath12k_ar_to_ah(ar);
+ unsigned long done_timeout = 3 * HZ;
unsigned long time_left;
int ret;
@@ -4859,15 +4860,32 @@ int ath12k_mac_get_fw_stats(struct ath12k *ar,
return -ETIMEDOUT;
}
+ /* VDEV stats are queried frequently from station info paths (e.g. iw/NM).
+ * On buggy firmware this path can timeout repeatedly and block callers for
+ * multiple seconds; keep the hot path responsive while preserving behavior
+ * for other stats types.
+ */
+ if (param->stats_id & WMI_REQUEST_VDEV_STAT)
+ done_timeout = msecs_to_jiffies(200);
+
+ /* Non-vdev/bcn stats are handled in a single event. */
+ if (!(param->stats_id & (WMI_REQUEST_VDEV_STAT | WMI_REQUEST_BCN_STAT)))
+ return 0;
+
/* Firmware sends WMI_UPDATE_STATS_EVENTID back-to-back
* when stats data buffer limit is reached. fw_stats_complete
* is completed once host receives first event from firmware, but
* still there could be more events following. Below is to wait
* until firmware completes sending all the events.
*/
- time_left = wait_for_completion_timeout(&ar->fw_stats_done, 3 * HZ);
+ time_left = wait_for_completion_timeout(&ar->fw_stats_done, done_timeout);
if (!time_left) {
- ath12k_warn(ab, "time out while waiting for fw stats done\n");
+ if (param->stats_id & WMI_REQUEST_VDEV_STAT)
+ ath12k_dbg(ab, ATH12K_DBG_WMI,
+ "time out while waiting for fw stats done (stats_id 0x%x)\n",
+ param->stats_id);
+ else
+ ath12k_warn(ab, "time out while waiting for fw stats done\n");
return -ETIMEDOUT;
}
--
2.47.3
^ permalink raw reply related
* [PATCH ath-next 1/4] wifi: ath12k: validate survey index when frequency is not found
From: m.limarencko @ 2026-02-09 3:02 UTC (permalink / raw)
To: jjohnson; +Cc: linux-wireless, ath12k, linux-kernel, Mikhail Limarenko
In-Reply-To: <20260209030243.1530075-1-m.limarencko@yandex.ru>
From: Mikhail Limarenko <m.limarencko@yandex.ru>
freq_to_idx() currently returns a monotonic index even when the
frequency was never matched.
In chan info paths this can lead to out-of-bounds survey indexing
for unexpected frequency events.
Return -EINVAL on no match and make callers reject negative
indexes.
Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
---
drivers/net/wireless/ath/ath12k/wmi.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index e647b84..422e3f8 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -6520,7 +6520,7 @@ static int freq_to_idx(struct ath12k *ar, int freq)
if (!sband)
continue;
- for (ch = 0; ch < sband->n_channels; ch++, idx++) {
+ for (ch = 0; ch < sband->n_channels; ch++) {
if (sband->channels[ch].center_freq <
KHZ_TO_MHZ(ar->freq_range.start_freq) ||
sband->channels[ch].center_freq >
@@ -6528,12 +6528,13 @@ static int freq_to_idx(struct ath12k *ar, int freq)
continue;
if (sband->channels[ch].center_freq == freq)
- goto exit;
+ return idx;
+
+ idx++;
}
}
-exit:
- return idx;
+ return -EINVAL;
}
static int ath12k_pull_chan_info_ev(struct ath12k_base *ab, struct sk_buff *skb,
@@ -7475,7 +7476,7 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
}
idx = freq_to_idx(ar, le32_to_cpu(ch_info_ev.freq));
- if (idx >= ARRAY_SIZE(ar->survey)) {
+ if (idx < 0 || idx >= ARRAY_SIZE(ar->survey)) {
ath12k_warn(ab, "chan info: invalid frequency %d (idx %d out of bounds)\n",
ch_info_ev.freq, idx);
goto exit;
@@ -7550,7 +7551,7 @@ ath12k_pdev_bss_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
spin_lock_bh(&ar->data_lock);
idx = freq_to_idx(ar, le32_to_cpu(bss_ch_info_ev.freq));
- if (idx >= ARRAY_SIZE(ar->survey)) {
+ if (idx < 0 || idx >= ARRAY_SIZE(ar->survey)) {
ath12k_warn(ab, "bss chan info: invalid frequency %d (idx %d out of bounds)\n",
bss_ch_info_ev.freq, idx);
goto exit;
--
2.47.3
^ permalink raw reply related
* [PATCH ath-next 0/4] wifi: ath12k: harden stats/rate handling for WCN785x stability
From: m.limarencko @ 2026-02-09 3:02 UTC (permalink / raw)
To: jjohnson; +Cc: linux-wireless, ath12k, linux-kernel, Mikhail Limarenko
From: Mikhail Limarenko <m.limarencko@yandex.ru>
Hi Jeff, all,
On QCNFA765/WCN785x (PCI, kernel 6.18.5) we observed three recurring
issues:
- chan info events with frequency not present in local survey range,
producing invalid idx warnings;
- frequent VDEV_STAT polling can block for 3 seconds on fw_stats_done
timeouts and cause visible hitches;
- occasional invalid MCS metadata (for example HE MCS=12) propagates
into mac80211 status handling and correlates with ieee80211_rx_list
warnings.
This series addresses those cases by:
1. returning -EINVAL from freq_to_idx() when no channel matches, and
rejecting negative indexes in callers;
2. reducing the wait on VDEV_STAT fw_stats completion and skipping
unnecessary waits for stats types that do not require it;
3. sanitizing invalid MCS metadata in both dp_rx and dp_mon paths by
falling back to legacy metadata with ratelimited diagnostics.
Tested on:
- hardware: QCNFA765 (WCN785x)
- kernel: 6.18.5+deb13-amd64
- AP mode: 5 GHz (802.11ac)
Observed after applying this series:
- station dump polling no longer shows multi-second stalls in test runs;
- no fresh ieee80211_rx_list WARN was observed in the same windows.
If patch 1/4 is already present in ath-next or stable trees, please drop
it and keep the remaining fixes.
Thanks,
Mikhail Limarenko
Mikhail Limarenko (4):
wifi: ath12k: validate survey index when frequency is not found
wifi: ath12k: avoid long fw_stats waits on vdev stats hot path
wifi: ath12k: sanitize invalid MCS metadata in rx path
wifi: ath12k: sanitize invalid MCS metadata in monitor rx path
drivers/net/wireless/ath/ath12k/dp_mon.c | 38 ++++++++++++++---------
drivers/net/wireless/ath/ath12k/dp_rx.c | 39 ++++++++++++++----------
drivers/net/wireless/ath/ath12k/mac.c | 22 +++++++++++--
drivers/net/wireless/ath/ath12k/wmi.c | 13 ++++----
4 files changed, 73 insertions(+), 39 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: fix indentation in ath12k_qmi_aux_uc_load()
From: Baochen Qiang @ 2026-02-09 2:52 UTC (permalink / raw)
To: Jeff Johnson
Cc: linux-wireless, ath12k, linux-kernel, kernel test robot,
Baochen Qiang
Smatch complains:
drivers/net/wireless/ath/ath12k/qmi.c:3342 ath12k_qmi_aux_uc_load() warn: inconsistent indenting
Fix it.
Compile tested only.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202602061221.5SCuwKhy-lkp@intel.com/
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
index cfde4147c8fc..41f53d34d33e 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.c
+++ b/drivers/net/wireless/ath/ath12k/qmi.c
@@ -3339,7 +3339,7 @@ static int ath12k_qmi_aux_uc_load(struct ath12k_base *ab)
goto out;
}
- aux_uc_mem->total_size = aux_uc_len;
+ aux_uc_mem->total_size = aux_uc_len;
copy:
memcpy(aux_uc_mem->vaddr, aux_uc_data, aux_uc_len);
---
base-commit: d9a2be2d72d4f9035f0334e0ff49180fe9df6e52
change-id: 20260206-ath12k-fix-indention-bfeaa64b072c
Best regards,
--
Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply related
* Re: New warning `ath10k_pci 0000:3a:00.0: not found station for peer stats`
From: Baochen Qiang @ 2026-02-09 2:44 UTC (permalink / raw)
To: Paul Menzel, Jeff Johnson; +Cc: linux-wireless, ath10k
In-Reply-To: <6a83fd12-edd8-4559-b7ba-75b074fa889f@molgen.mpg.de>
On 2/7/2026 1:55 PM, Paul Menzel wrote:
> [Cc: +Baochen]
>
> Dear Linux folks,
>
>
> Am 19.01.26 um 17:41 schrieb Paul Menzel:
>
>> Since January 10th, I have started seeing the warning below in my Linux logs, that reach
>> back to September 24th, 2025:
>>
>> [ 37.108902] ath10k_pci 0000:3a:00.0: not found station for peer stats
>> [ 37.108906] ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>>
>> It started appearing with 6.19.0-rc4-00282-gb6151c4e60e5, the version running before is
>> 6.19.0-rc4-00003-g3609fa95fb0f, but I do not see anything related in the commit list:
>>
>> git log --oneline 3609fa95fb0f...b6151c4e60e5
>>
>> The warning log from `drivers/net/wireless/ath/ath10k/wmi-tlv.c` has also been there
>> since 2021.
>>
>> Do you have an idea? Please find the output of `dmesg` attached.
>
> Looking through the commit list from above again, commit a203dbeeca15 (wifi: mac80211:
> collect station statistics earlier when disconnect) probably introduced the new behavior.
>
is this error seen when disconnecting from AP? did you try with that commit reverted?
>
> Kind regards,
>
> Paul
^ permalink raw reply
* iwlwifi: missing bz-b0-hr-b0 firmware ≥99; driver minimum bumped in 6.18 but no firmware released
From: Maxim Schoening @ 2026-02-08 21:23 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: miriam.rachel.korenblit@intel.com
Hi,
The iwlwifi-bz-b0-hr-b0 firmware has not been updated past version 98 (core98-161, October 2025), but the 6.18 kernel's iwlwifi driver has raised ucode_api_min above 98 for this device class, resulting in complete Wi-Fi failure.
On 6.17.9, the driver falls back to 98 successfully:
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-100.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-99.ucode failed with error -2
iwlwifi 0000:00:14.3: loaded firmware version 98.d661c37c.0 bz-b0-hr-b0-98.ucode op_mode iwlmvm
On 6.18.7, the fallback no longer works and Wi-Fi is completely broken.
Neither iwlwifi-bz-b0-hr-b0-99.ucode nor -100.ucode exist in mainline linux-firmware or the iwlwifi for-upstream branch.
Other Bz variants have been actively updated during this period: bz-b0-gf-a0: updated to 100 bz-b0-fm-c0: updated to c102 bz-b0-hr-b0: stuck at 98 since October 2025 The most recent for-upstream commit (9a9285ce, 2026-01-15, "iwlwifi: add Bz/Sc FW for core102-56 release") adds firmware for Bz/Fm and gl but not Bz/Hr.
This looks like a coordination gap: ucode_api_min was bumped without matching firmware being released for all affected sub-variants.
Affected hardware: [17.350374] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX203
Device: Xiaomi Redmi Book Pro 2025 PCI ID: 8086:7740
PCI path: 0000:00:14.3
Variant: bz-b0-hr-b0 (Blazer CNVi + Harrison Peak radio)
Working: 6.17.9-76061709-generic
Broken: 6.18.7-76061807-generic
This is the same device class previously affected by LP #2102029, which was resolved when bz-b0-hr-b0-96.ucode was added in the core93-123 release.
Could the Bz/Hr firmware be brought up to match the other Bz variants, or alternatively, could the ucode_api_min for bz-b0-hr-b0 be reverted to 98 until the firmware is available?
Thanks a lot!
Best,
Maxim
^ permalink raw reply
* miriam.rachel.korenblit@intel.com
From: Maxim Schoening @ 2026-02-08 21:18 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
The iwlwifi-bz-b0-hr-b0 firmware has not been updated past version 98 (core98-161, October 2025), but the 6.18 kernel's iwlwifi driver has raised ucode_api_min above 98 for this device class, resulting in complete Wi-Fi failure.
On 6.17.9, the driver falls back to 98 successfully:
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-100.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-bz-b0-hr-b0-99.ucode failed with error -2
iwlwifi 0000:00:14.3: loaded firmware version 98.d661c37c.0 bz-b0-hr-b0-98.ucode op_mode iwlmvm
On 6.18.7, the fallback no longer works and Wi-Fi is completely broken.
Neither iwlwifi-bz-b0-hr-b0-99.ucode nor -100.ucode exist in mainline linux-firmware or the iwlwifi for-upstream branch. Other Bz variants have been actively updated during this period:
bz-b0-gf-a0: updated to 100 bz-b0-fm-c0: updated to c102 bz-b0-hr-b0: stuck at 98 since October 2025
The most recent for-upstream commit (9a9285ce, 2026-01-15, "iwlwifi: add Bz/Sc FW for core102-56 release") adds firmware for Bz/Fm and gl but not Bz/Hr.
This looks like a coordination gap: ucode_api_min was bumped without matching firmware being released for all affected sub-variants.
Affected hardware:
[17.350374] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6 AX203
Device:
Xiaomi Redmi Book Pro 2025 PCI ID: 8086:7740 PCI path: 0000:00:14.3 Variant: bz-b0-hr-b0 (Blazer CNVi + Harrison Peak radio)
Working: 6.17.9-76061709-generic
Broken: 6.18.7-76061807-generic
This is the same device class previously affected by LP #2102029, which was resolved when bz-b0-hr-b0-96.ucode was added in the core93-123 release.
Could the Bz/Hr firmware be brought up to match the other Bz variants, or alternatively, could the ucode_api_min for bz-b0-hr-b0 be reverted to 98 until the firmware is available?
Thanks a lot!
Best,
Maxim
^ permalink raw reply
* Re: [syzbot] [wireless?] WARNING in ieee80211_tx_h_rate_ctrl
From: syzbot @ 2026-02-08 18:47 UTC (permalink / raw)
To: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <68385415.a70a0220.29d4a0.082e.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 6d2f142b1e4b net: hns3: fix double free issue for tx spare..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=13ade7fa580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e3161cabe5a361ff
dashboard link: https://syzkaller.appspot.com/bug?extid=0d516b33238bd97ee864
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=178a965a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141bb65a580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/efb336297393/disk-6d2f142b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c21fa89166f7/vmlinux-6d2f142b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9404edc5fcc0/bzImage-6d2f142b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0d516b33238bd97ee864@syzkaller.appspotmail.com
------------[ cut here ]------------
wlan1: Dropped data frame as no usable bitrate found while scanning and associated. Target station: 08:02:11:00:00:00 on 5 GHz band
WARNING: net/mac80211/tx.c:758 at ieee80211_tx_h_rate_ctrl+0xd82/0x1760 net/mac80211/tx.c:751, CPU#1: kworker/u8:8/3000
Modules linked in:
CPU: 1 UID: 0 PID: 3000 Comm: kworker/u8:8 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026
Workqueue: events_unbound cfg80211_wiphy_work
RIP: 0010:ieee80211_tx_h_rate_ctrl+0xded/0x1760 net/mac80211/tx.c:751
Code: 1c 08 00 00 48 8b 44 24 38 8b 30 45 31 ed 83 e6 07 41 0f 95 c5 31 ff e8 01 3c b2 f6 43 8d 4c 6d 02 48 89 df 4c 89 f6 4c 89 fa <67> 48 0f b9 3a 41 bd 01 00 00 00 e9 73 01 00 00 e8 9e 37 b2 f6 e9
RSP: 0018:ffffc9000b7173c0 EFLAGS: 00010293
RAX: ffffffff8b123f8f RBX: ffffffff900054b0 RCX: 0000000000000005
RDX: ffff88805e97c384 RSI: ffff8880783817c8 RDI: ffffffff900054b0
RBP: ffffc9000b717528 R08: ffff88807cad29c7 R09: 1ffff1100f95a538
R10: dffffc0000000000 R11: ffffed100f95a539 R12: dffffc0000000000
R13: 0000000000000001 R14: ffff8880783817c8 R15: ffff88805e97c384
FS: 0000000000000000(0000) GS:ffff8881257f5000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdf034708c0 CR3: 0000000079e3a000 CR4: 00000000003526f0
Call Trace:
<TASK>
invoke_tx_handlers_late+0xba/0x18a0 net/mac80211/tx.c:1849
ieee80211_tx+0x2d7/0x4b0 net/mac80211/tx.c:1971
__ieee80211_tx_skb_tid_band+0x50f/0x680 net/mac80211/tx.c:6288
ieee80211_tx_skb_tid_band net/mac80211/ieee80211_i.h:2405 [inline]
ieee80211_send_scan_probe_req net/mac80211/scan.c:685 [inline]
ieee80211_scan_state_send_probe+0x594/0xa00 net/mac80211/scan.c:713
ieee80211_scan_work+0x65f/0x1c50 net/mac80211/scan.c:1174
cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438
process_one_work kernel/workqueue.c:3257 [inline]
process_scheduled_works+0xaec/0x17a0 kernel/workqueue.c:3340
worker_thread+0xda6/0x1360 kernel/workqueue.c:3421
kthread+0x726/0x8b0 kernel/kthread.c:463
ret_from_fork+0x51b/0xa40 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
</TASK>
----------------
Code disassembly (best guess):
0: 1c 08 sbb $0x8,%al
2: 00 00 add %al,(%rax)
4: 48 8b 44 24 38 mov 0x38(%rsp),%rax
9: 8b 30 mov (%rax),%esi
b: 45 31 ed xor %r13d,%r13d
e: 83 e6 07 and $0x7,%esi
11: 41 0f 95 c5 setne %r13b
15: 31 ff xor %edi,%edi
17: e8 01 3c b2 f6 call 0xf6b23c1d
1c: 43 8d 4c 6d 02 lea 0x2(%r13,%r13,2),%ecx
21: 48 89 df mov %rbx,%rdi
24: 4c 89 f6 mov %r14,%rsi
27: 4c 89 fa mov %r15,%rdx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 41 bd 01 00 00 00 mov $0x1,%r13d
35: e9 73 01 00 00 jmp 0x1ad
3a: e8 9e 37 b2 f6 call 0xf6b237dd
3f: e9 .byte 0xe9
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* [PATCH] mesh: don't incorrectly use const
From: Rudi Heitbaum @ 2026-02-08 11:45 UTC (permalink / raw)
To: johannes; +Cc: rudi, linux-wireless
*name is used by strchr and subsequently modified replacing "="
with '\0'. Remove incorrect and unnecessary const. Passed in argv[]
is editable, and is being modified in the function.
Fixes:
mesh.c: In function 'set_interface_meshparam':
mesh.c:327:23: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
327 | value = strchr(name, '=');
| ^
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
---
mesh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mesh.c b/mesh.c
index 40e5e5e..f116ae7 100644
--- a/mesh.c
+++ b/mesh.c
@@ -317,7 +317,7 @@ static int set_interface_meshparam(struct nl80211_state *state,
}
while (argc) {
- const char *name;
+ char *name;
char *value;
_any any;
--
2.51.0
^ permalink raw reply related
* [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Sai Pratyusha Magam @ 2026-02-08 8:18 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, sai.magam, quic_drohan
Per IEEE Std 802.11be-2024, 12.5.2.3.3, if the MPDU is an
individually addressed Data frame between an AP MLD and a
non-AP MLD associated with the AP MLD, then A1/A2/A3
will be MLD MAC addresses. Otherwise, Al/A2/A3 will be
over-the-air link MAC addresses.
Currently, during AAD and Nonce computation for software based
encryption/decryption cases, mac80211 directly uses the addresses it
receives in the skb frame header. However, after the first
authentication, management frame addresses for non-AP MLD stations
are translated to MLD addresses from over the air link addresses in
software. This means that the skb header could contain translated MLD
addresses, which when used as is, can lead to incorrect AAD/Nonce
computation.
In the following manner, ensure that the right set of addresses are used:
In the receive path, stash the pre-translated link addresses in
ieee80211_rx_data and use them for the AAD/Nonce computations in the
decrypt path for robust management frames (MFP) and (Re)Association
Request/Response frames that require encryption (EPP)
In the transmit path, offload the encryption of robust
management frames (MFP) and (Re)Association Request/Response
frames that require encryption (EPP) to the hwsim driver that
can then ensure that encryption and hence the AAD/Nonce computations
are performed on the frame containing the link addresses.
To do so, register the set key handler in hwsim driver so mac80211 is
aware that it is the driver that would take care of encrypting the
frame. The key flag IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD selectively
offloads only encryption of management frames, while keeping the
encryption for data frames and MMIE generation for a AES_CMAC or a
AES_GMAC key still at the SW crypto in mac layer
The hybrid way of having both HW/driver based crypto for certain frames
and SW crypto for others require that the fast-xmit path be skipped
when the above mentioned key flag is set, since data frames still rely
on software based crypto and also that sufficient tailroom is always
reserved in the skb for ICV/MIC addition.
Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>
---
v1 -> v2:
Removed the additional address translation to link addresses approach
in the encrypt/decrypt path for management frames and instead the rx
path uses the stashed pre-translated link addresses for decryption and
in the tx path, encryption for mgmt frames is offloaded to hwsim driver
drivers/net/wireless/virtual/mac80211_hwsim.c | 19 ++++++
include/net/mac80211.h | 11 ++++
net/mac80211/cfg.c | 4 +-
net/mac80211/ieee80211_i.h | 15 +++++
net/mac80211/rx.c | 3 +
net/mac80211/tx.c | 60 ++++++++++++++++++-
net/mac80211/wpa.c | 57 ++++++++++++++----
7 files changed, 153 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 4d9f5f87e814..9a364c6774a5 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -1955,6 +1955,16 @@ mac80211_hwsim_select_tx_link(struct mac80211_hwsim_data *data,
return NULL;
}
+static int mac80211_hwsim_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ struct ieee80211_key_conf *key)
+{
+ key->flags |= IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD |
+ IEEE80211_KEY_FLAG_RESERVE_TAILROOM;
+ return 0;
+}
+
static void mac80211_hwsim_tx(struct ieee80211_hw *hw,
struct ieee80211_tx_control *control,
struct sk_buff *skb)
@@ -2060,6 +2070,13 @@ static void mac80211_hwsim_tx(struct ieee80211_hw *hw,
}
}
+ if (ieee80211_encrypt_tx_skb(skb) < 0) {
+ ieee80211_free_txskb(hw, skb);
+ return;
+ }
+ /* re-assign hdr since skb data may have shifted after encryption */
+ hdr = (void *)skb->data;
+
if (WARN(!channel, "TX w/o channel - queue = %d\n", txi->hw_queue)) {
ieee80211_free_txskb(hw, skb);
return;
@@ -4189,6 +4206,7 @@ static int mac80211_hwsim_change_nan_config(struct ieee80211_hw *hw,
.start_nan = mac80211_hwsim_start_nan, \
.stop_nan = mac80211_hwsim_stop_nan, \
.nan_change_conf = mac80211_hwsim_change_nan_config, \
+ .set_key = mac80211_hwsim_set_key, \
HWSIM_DEBUGFS_OPS
#define HWSIM_NON_MLO_OPS \
@@ -5621,6 +5639,7 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
WIPHY_FLAG_AP_UAPSD |
WIPHY_FLAG_SUPPORTS_5_10_MHZ |
WIPHY_FLAG_HAS_CHANNEL_SWITCH;
+ hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
hw->wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR |
NL80211_FEATURE_AP_MODE_CHAN_WIDTH_CHANGE |
NL80211_FEATURE_STATIC_SMPS |
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7f9d96939a4e..69530aa913be 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2242,6 +2242,9 @@ static inline bool lockdep_vif_wiphy_mutex_held(struct ieee80211_vif *vif)
* number generation only
* @IEEE80211_KEY_FLAG_SPP_AMSDU: SPP A-MSDUs can be used with this key
* (set by mac80211 from the sta->spp_amsdu flag)
+ * @IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD: This flag should be set by
+ * the driver for a key if encryption of only management frames (MFP)
+ * is offloaded to the driver
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT = BIT(0),
@@ -2256,6 +2259,7 @@ enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_NO_AUTO_TX = BIT(9),
IEEE80211_KEY_FLAG_GENERATE_MMIE = BIT(10),
IEEE80211_KEY_FLAG_SPP_AMSDU = BIT(11),
+ IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD = BIT(12),
};
/**
@@ -7962,4 +7966,11 @@ int ieee80211_emulate_switch_vif_chanctx(struct ieee80211_hw *hw,
* Return: %true iff the vif is a NAN interface and NAN is started
*/
bool ieee80211_vif_nan_started(struct ieee80211_vif *vif);
+
+/**
+ * ieee80211_encrypt_tx_skb - Encrypt the transmit skb
+ * @skb: the skb
+ * Return: 0 if success and non-zero on error
+ */
+int ieee80211_encrypt_tx_skb(struct sk_buff *skb);
#endif /* MAC80211_H */
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5d04d7d550b0..d48a53ebb98f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -885,7 +885,9 @@ static int ieee80211_get_key(struct wiphy *wiphy, struct net_device *dev,
offsetof(typeof(kseq), gcmp));
if (key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE &&
- !(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV)) {
+ !(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
+ !(key->conf.flags &
+ IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD)) {
drv_get_key_seq(sdata->local, key, &kseq);
memcpy(seq, kseq.ccmp.pn, 6);
} else {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e60b814dd89e..5fe561fd09f2 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -256,6 +256,8 @@ struct ieee80211_rx_data {
u8 pn[IEEE80211_CCMP_PN_LEN];
} ccm_gcm;
};
+
+ u8 link_addrs[3 * ETH_ALEN];
};
struct ieee80211_csa_settings {
@@ -2404,6 +2406,19 @@ static inline bool ieee80211_require_encrypted_assoc(__le16 fc,
ieee80211_is_assoc_resp(fc) || ieee80211_is_reassoc_resp(fc)));
}
+static inline bool ieee80211_require_sw_tx_enc(__le16 fc, u16 flags,
+ struct sta_info *sta,
+ struct sk_buff *skb)
+{
+ struct ieee80211_hdr *hdr = (void *)skb->data;
+ bool unicast_robust_mgmt = is_unicast_ether_addr(hdr->addr1) &&
+ ieee80211_is_robust_mgmt_frame(skb);
+
+ return ((flags & IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) &&
+ !unicast_robust_mgmt &&
+ !ieee80211_require_encrypted_assoc(fc, sta));
+}
+
/* sta_out needs to be checked for ERR_PTR() before using */
int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 11d6c56c9d7e..e8eb38cbafc6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -5127,6 +5127,9 @@ static bool ieee80211_prepare_and_rx_handle(struct ieee80211_rx_data *rx,
hdr = (struct ieee80211_hdr *)rx->skb->data;
}
+ /* Store a copy of the pre-translated link addresses */
+ memcpy(rx->link_addrs, &hdr->addrs, 3 * ETH_ALEN);
+
if (unlikely(rx->sta && rx->sta->sta.mlo) &&
is_unicast_ether_addr(hdr->addr1) &&
!ieee80211_is_probe_resp(hdr->frame_control) &&
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 007f5a368d41..ca756868594d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -632,6 +632,11 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
case WLAN_CIPHER_SUITE_TKIP:
if (!ieee80211_is_data_present(hdr->frame_control))
tx->key = NULL;
+ else
+ skip_hw = ieee80211_require_sw_tx_enc(hdr->frame_control,
+ tx->key->conf.flags,
+ tx->sta,
+ tx->skb);
break;
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
@@ -645,9 +650,13 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
tx->sta))
tx->key = NULL;
else
- skip_hw = (tx->key->conf.flags &
- IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
- ieee80211_is_mgmt(hdr->frame_control);
+ skip_hw = ((tx->key->conf.flags &
+ IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
+ ieee80211_is_mgmt(hdr->frame_control)) ||
+ ieee80211_require_sw_tx_enc(hdr->frame_control,
+ tx->key->conf.flags,
+ tx->sta,
+ tx->skb);
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
case WLAN_CIPHER_SUITE_BIP_CMAC_256:
@@ -655,6 +664,11 @@ ieee80211_tx_h_select_key(struct ieee80211_tx_data *tx)
case WLAN_CIPHER_SUITE_BIP_GMAC_256:
if (!ieee80211_is_mgmt(hdr->frame_control))
tx->key = NULL;
+ else
+ skip_hw = ieee80211_require_sw_tx_enc(hdr->frame_control,
+ tx->key->conf.flags,
+ tx->sta,
+ tx->skb);
break;
}
@@ -3205,6 +3219,13 @@ void ieee80211_check_fast_xmit(struct sta_info *sta)
if (!(build.key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
goto out;
+ /* Only management frame encryption is offloaded to the driver,
+ * So skip fast-xmit
+ */
+ if (build.key->conf.flags &
+ IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD)
+ goto out;
+
/* Key is being removed */
if (build.key->flags & KEY_FLAG_TAINTED)
goto out;
@@ -5299,6 +5320,7 @@ static int ieee80211_beacon_protect(struct sk_buff *skb,
}
if (!(tx.key->conf.flags & IEEE80211_KEY_FLAG_SW_MGMT_TX) &&
+ !(tx.key->conf.flags & IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) &&
tx.key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE)
IEEE80211_SKB_CB(skb)->control.hw_key = &tx.key->conf;
@@ -5316,6 +5338,38 @@ static int ieee80211_beacon_protect(struct sk_buff *skb,
return 0;
}
+int ieee80211_encrypt_tx_skb(struct sk_buff *skb)
+{
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_sub_if_data *sdata;
+ struct sk_buff *check_skb;
+ struct ieee80211_tx_data tx;
+ ieee80211_tx_result res;
+
+ if (!info->control.hw_key)
+ return 0;
+
+ memset(&tx, 0, sizeof(tx));
+ tx.key = container_of(info->control.hw_key, struct ieee80211_key, conf);
+ /* NULL it out now so we do full SW crypto */
+ info->control.hw_key = NULL;
+ __skb_queue_head_init(&tx.skbs);
+ __skb_queue_tail(&tx.skbs, skb);
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(skb->dev);
+ tx.sdata = sdata;
+ tx.local = sdata->local;
+ res = ieee80211_tx_h_encrypt(&tx);
+ check_skb = __skb_dequeue(&tx.skbs);
+ /* we may crash after this, but it'd be a bug in crypto */
+ WARN_ON(check_skb != skb);
+ if (WARN_ON_ONCE(res != TX_CONTINUE))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ieee80211_encrypt_tx_skb);
+
static void
ieee80211_beacon_get_finish(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index fdf98c21d32c..9d10e82fcf1c 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -315,7 +315,8 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
* Calculate AAD for CCMP/GCMP, returning qos_tid since we
* need that in CCMP also for b_0.
*/
-static u8 ccmp_gcmp_aad(struct sk_buff *skb, u8 *aad, bool spp_amsdu)
+static u8 ccmp_gcmp_aad(struct sk_buff *skb, u8 *aad, bool spp_amsdu,
+ bool aad_nonce_computed)
{
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 mask_fc;
@@ -358,7 +359,8 @@ static u8 ccmp_gcmp_aad(struct sk_buff *skb, u8 *aad, bool spp_amsdu)
* FC | A1 | A2 | A3 | SC | [A4] | [QC] */
put_unaligned_be16(len_a, &aad[0]);
put_unaligned(mask_fc, (__le16 *)&aad[2]);
- memcpy(&aad[4], &hdr->addrs, 3 * ETH_ALEN);
+ if (!aad_nonce_computed)
+ memcpy(&aad[4], &hdr->addrs, 3 * ETH_ALEN);
/* Mask Seq#, leave Frag# */
aad[22] = *((u8 *) &hdr->seq_ctrl) & 0x0f;
@@ -377,10 +379,10 @@ static u8 ccmp_gcmp_aad(struct sk_buff *skb, u8 *aad, bool spp_amsdu)
}
static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *b_0, u8 *aad,
- bool spp_amsdu)
+ bool spp_amsdu, bool aad_nonce_computed)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- u8 qos_tid = ccmp_gcmp_aad(skb, aad, spp_amsdu);
+ u8 qos_tid = ccmp_gcmp_aad(skb, aad, spp_amsdu, aad_nonce_computed);
/* In CCM, the initial vectors (IV) used for CTR mode encryption and CBC
* mode authentication are not allowed to collide, yet both are derived
@@ -395,7 +397,8 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *b_0, u8 *aad,
* Nonce Flags: Priority (b0..b3) | Management (b4) | Reserved (b5..b7)
*/
b_0[1] = qos_tid | (ieee80211_is_mgmt(hdr->frame_control) << 4);
- memcpy(&b_0[2], hdr->addr2, ETH_ALEN);
+ if (!aad_nonce_computed)
+ memcpy(&b_0[2], hdr->addr2, ETH_ALEN);
memcpy(&b_0[8], pn, IEEE80211_CCMP_PN_LEN);
}
@@ -488,7 +491,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
pos += IEEE80211_CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, b_0, aad,
- key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU);
+ key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU,
+ false);
return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
skb_put(skb, mic_len));
}
@@ -566,9 +570,23 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
if (!(status->flag & RX_FLAG_DECRYPTED)) {
u8 aad[2 * AES_BLOCK_SIZE];
u8 b_0[AES_BLOCK_SIZE];
+ bool aad_nonce_computed = false;
+
+ if (ieee80211_is_robust_mgmt_frame(skb) ||
+ ieee80211_require_encrypted_assoc(hdr->frame_control,
+ rx->sta)) {
+ /* AAD computation */
+ memcpy(&aad[4], rx->link_addrs, 3 * ETH_ALEN);
+ /* Nonce computation */
+ ether_addr_copy(&b_0[2],
+ &rx->link_addrs[ETH_ALEN]);
+ aad_nonce_computed = true;
+ }
+
/* hardware didn't decrypt/verify MIC */
ccmp_special_blocks(skb, pn, b_0, aad,
- key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU);
+ key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU,
+ aad_nonce_computed);
if (ieee80211_aes_ccm_decrypt(
key->u.ccmp.tfm, b_0, aad,
@@ -593,14 +611,15 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
}
static void gcmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *j_0, u8 *aad,
- bool spp_amsdu)
+ bool spp_amsdu, bool aad_nonce_computed)
{
struct ieee80211_hdr *hdr = (void *)skb->data;
- memcpy(j_0, hdr->addr2, ETH_ALEN);
+ if (!aad_nonce_computed)
+ memcpy(j_0, hdr->addr2, ETH_ALEN);
memcpy(&j_0[ETH_ALEN], pn, IEEE80211_GCMP_PN_LEN);
- ccmp_gcmp_aad(skb, aad, spp_amsdu);
+ ccmp_gcmp_aad(skb, aad, spp_amsdu, aad_nonce_computed);
}
static inline void gcmp_pn2hdr(u8 *hdr, const u8 *pn, int key_id)
@@ -690,7 +709,8 @@ static int gcmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
pos += IEEE80211_GCMP_HDR_LEN;
gcmp_special_blocks(skb, pn, j_0, aad,
- key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU);
+ key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU,
+ false);
return ieee80211_aes_gcm_encrypt(key->u.gcmp.tfm, j_0, aad, pos, len,
skb_put(skb, IEEE80211_GCMP_MIC_LEN));
}
@@ -763,9 +783,22 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data *rx)
if (!(status->flag & RX_FLAG_DECRYPTED)) {
u8 aad[2 * AES_BLOCK_SIZE];
u8 j_0[AES_BLOCK_SIZE];
+ bool aad_nonce_computed = false;
+
+ if (ieee80211_is_robust_mgmt_frame(skb) ||
+ ieee80211_require_encrypted_assoc(hdr->frame_control,
+ rx->sta)) {
+ /* AAD computation */
+ memcpy(&aad[4], rx->link_addrs, 3 * ETH_ALEN);
+ /* Nonce computation */
+ ether_addr_copy(&j_0[0],
+ &rx->link_addrs[ETH_ALEN]);
+ aad_nonce_computed = true;
+ }
/* hardware didn't decrypt/verify MIC */
gcmp_special_blocks(skb, pn, j_0, aad,
- key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU);
+ key->conf.flags & IEEE80211_KEY_FLAG_SPP_AMSDU,
+ aad_nonce_computed);
if (ieee80211_aes_gcm_decrypt(
key->u.gcmp.tfm, j_0, aad,
base-commit: 333225e1e9ead7b06e5363389403bdac72ba3046
--
2.34.1
^ permalink raw reply related
* [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Bitterblue Smith @ 2026-02-07 22:29 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
When connected to a network in the 2.4 GHz band, wpa_supplicant (or
NetworkManager?) triggers a scan every five minutes. During these scans
mac80211 transmits many QoS Null frames in quick succession. Because
these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
asks the firmware to report the TX ACK status for each of these frames.
Sometimes the firmware can't process the TX status requests quickly
enough, they add up, it only processes some of them, and then marks
every subsequent TX status report with the wrong number.
The symptom is that after a while the warning "failed to get tx report
from firmware" appears every five minutes.
This problem apparently happens only with the older RTL8723D, RTL8821A,
RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
number reported by these chips and match the reports with the requests
in the order they come in.
Tested with RTL8821AU and RTL8723DU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
---
drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
index c04ff31d0f1e..98215ecc884a 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.c
+++ b/drivers/net/wireless/realtek/rtw88/tx.c
@@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
spin_lock_irqsave(&tx_report->q_lock, flags);
skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
- if (*n == sn) {
+ if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
__skb_unlink(cur, &tx_report->queue);
rtw_tx_report_tx_status(rtwdev, cur, st == 0);
break;
--
2.52.0
^ permalink raw reply related
* [PATCH] wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()
From: Alexey Velichayshiy @ 2026-02-07 15:03 UTC (permalink / raw)
To: a.velichayshiy, Miri Korenblit
Cc: Johannes Berg, Emmanuel Grumbach, Pagadala Yesu Anjaneyulu,
linux-wireless, linux-kernel, lvc-project
The memcpy function assumes the dynamic array notif->matches is at least
as large as the number of bytes to copy. Otherwise, results->matches may
contain unwanted data. To guarantee safety, extend the validation in one
of the checks to ensure sufficient packet length.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexey Velichayshiy <a.velichayshiy@ispras.ru>
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 07f1a84c274e..c3ad414ac85e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -2834,7 +2834,7 @@ static void iwl_mvm_nd_match_info_handler(struct iwl_mvm *mvm,
if (IS_ERR_OR_NULL(vif))
return;
- if (len < sizeof(struct iwl_scan_offload_match_info)) {
+ if (len < sizeof(struct iwl_scan_offload_match_info) + matches_len) {
IWL_ERR(mvm, "Invalid scan match info notification\n");
return;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH wireless] wifi: mac80211: skip BSS_CHANGED_TXPOWER for monitor interfaces
From: Krzysztof Kozlowski @ 2026-02-07 11:06 UTC (permalink / raw)
To: Dhyan K Prajapati, Lachlan Hodges, Johannes Berg
Cc: linux-wireless, linux-kernel, Dhyan K Prajapati
In-Reply-To: <20260207110224.32755-1-dhyan19022009@gmail.com>
On 07/02/2026 12:02, Dhyan K Prajapati wrote:
> Monitor mode interfaces do not maintain a BSS context, since a commit in
> July 2025 monitor interfaces with WANT_MONITOR_VIF began receiving link
> change notification duing ieee80211_add_vitual_monitor(), when
> ieee_assign_link_chanctx() assigns a channel context, it triggers
> ieee80211_recalc_txpower() this sends a bss_info_changed callback
> receive link->conf as the bss_conf prameter, in monitor mode it isn't
> initialised leading to NULL pointer dereference in drivers like iwldvm,
> as BSS_CHANGED_TXPOWER is not applicable for monitor mode we can just
Impossible to understand.
> skip it.
>
> Fixes: c57e5b9819df ("wifi: mac80211: fix WARN_ON for monitor mode on some devices")
> Tested-by: Dhyan K Prajapati <dhyan1902209@gmail.com>
No, you are the same person.
Plus I do not believe that this is anything more than microslop AI.
You ignore people's feedback, do not respond to it, do not version your
patches (still!). Start reading and responding the feedback. Provide
proofs (e.g. by improving your contributions) that you actually read
what we asked.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH wireless] wifi: mac80211: skip BSS_CHANGED_TXPOWER for monitor interfaces
From: Dhyan K Prajapati @ 2026-02-07 11:02 UTC (permalink / raw)
To: Lachlan Hodges, Johannes Berg
Cc: Krzysztof Kozlowski, linux-wireless, linux-kernel,
Dhyan K Prajapati, Dhyan K Prajapati
Monitor mode interfaces do not maintain a BSS context, since a commit in
July 2025 monitor interfaces with WANT_MONITOR_VIF began receiving link
change notification duing ieee80211_add_vitual_monitor(), when
ieee_assign_link_chanctx() assigns a channel context, it triggers
ieee80211_recalc_txpower() this sends a bss_info_changed callback
receive link->conf as the bss_conf prameter, in monitor mode it isn't
initialised leading to NULL pointer dereference in drivers like iwldvm,
as BSS_CHANGED_TXPOWER is not applicable for monitor mode we can just
skip it.
Fixes: c57e5b9819df ("wifi: mac80211: fix WARN_ON for monitor mode on some devices")
Tested-by: Dhyan K Prajapati <dhyan1902209@gmail.com>
Signed-off-by: Dhyan K Prajapati <dhyan19022009@gmail.com>
---
net/mac80211/iface.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 515384ca2..47f6bef0e 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -76,8 +76,9 @@ bool __ieee80211_recalc_txpower(struct ieee80211_link_data *link)
void ieee80211_recalc_txpower(struct ieee80211_link_data *link,
bool update_bss)
{
- if (__ieee80211_recalc_txpower(link) ||
- (update_bss && ieee80211_sdata_running(link->sdata)))
+ if (link->sdata->vif.type != NL80211_IFTYPE_MONITOR &&
+ (__ieee80211_recalc_txpower(link) ||
+ (update_bss && ieee80211_sdata_running(link->sdata))))
ieee80211_link_info_change_notify(link->sdata, link,
BSS_CHANGED_TXPOWER);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: mac80211: skip BSS_CHANGED_TXPOWER notification for monitor mode
From: Krzysztof Kozlowski @ 2026-02-07 9:41 UTC (permalink / raw)
To: Dhyan K Prajapati, Johannes Berg
Cc: linux-wireless, linux-kernel, Dhyan K Prajapati
In-Reply-To: <20260207050035.6720-1-dhyan19022009@gmail.com>
On 07/02/2026 06:00, Dhyan K Prajapati wrote:
> From: Dhyan K Prajapati <dhyaan19022009@gmail.com>
>
> Monitor mode interfaces don't maintain BSS context. The BSS_CHANGED_TXPOWER notification
> indicates transmit power constrains recieved from an associated access point which isn't really
> applicable to monitor mode as it does not associate with any BSS
>
> after a commit back in july 2025,("wifi: mac80211: fix WARN_ON for monitor mode
> on some devices") monitor interfaces with WANT_MONITOR_VIF began recieving link
> change notifications during ieee_add_virtual_monitor(), when ieee_link_use_channel()
> assigns a channel context it triggers ieee_recalc_power() which sends BSS_CHANGED_TXPOWER
> notifications to driver, driver using legacy bss_info_changed callbeack recieve
> link->conf as the bss_conf parameter for monitor mode that points to vif.bss_conf which is not fully initialised
> in monitor interfaces, so drivers like iwldvm dereference null and crash
> since BSS_CHANGED_TXPOWER notifications are meaningless for monitor mode, we can skip
> the notification entirely,monitor mode transmit power remains configurable via
You keep sending us microslop AI, so I don't think it is worth reviewing it.
> nl80211
> Hardware: Dell Latitude E6430
> Device: Intel Centrino Advanced-N 6205 [Taylor Peak]
>
> Crash trace:
> BUG: kernel NULL pointer dereference at 0000000000000000
> RIP: iwlagn_bss_info_changed+0x19d/0x640 [iwldvm]
> Call Trace:
> drv_link_info_changed+0x2b5/0x2c0
> ieee80211_link_info_change_notify+0x13d/0x160
> __ieee80211_recalc_txpower+0x44/0xd0
> ieee80211_recalc_txpower+0x5c/0x60
> ieee80211_assign_link_chanctx+0x182/0x410
> ieee80211_link_use_channel+0x413/0x450
> ieee80211_add_virtual_monitor+0x17c/0x2b0
>
> Tested-by: Dhyan K Prajapati <dhyan19022009@gmail.com>
No, wasn't. AI is not testing.
> Signed-off-by: Dhyan K Prajapati <dhyan19022009@gmail.com>
> ---
> net/mac80211/iface.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] wifi: ath10k: Fix error handling in ath10k_ahb_clock_init()
From: Alper Ak @ 2026-02-07 8:24 UTC (permalink / raw)
To: Jeff Johnson
Cc: Alper Ak, Kalle Valo, Raja Mani, linux-wireless, ath10k,
linux-kernel
The devm_clk_get() function never returns NULL, it only returns valid
clock pointers or an ERR_PTR() on failure. Using IS_ERR_OR_NULL() is
incorrect and causes static analyzer warnings about passing zero to
PTR_ERR() when the theoretical NULL case is handled.
Fixes: 8beff219c528 ("ath10k: add clock ctrl related functions in ahb")
Signed-off-by: Alper Ak <alperyasinak1@gmail.com>
---
drivers/net/wireless/ath/ath10k/ahb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index eb8b35b6224d..7456f885d2b5 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -87,24 +87,24 @@ static int ath10k_ahb_clock_init(struct ath10k *ar)
dev = &ar_ahb->pdev->dev;
ar_ahb->cmd_clk = devm_clk_get(dev, "wifi_wcss_cmd");
- if (IS_ERR_OR_NULL(ar_ahb->cmd_clk)) {
+ if (IS_ERR(ar_ahb->cmd_clk)) {
ath10k_err(ar, "failed to get cmd clk: %ld\n",
PTR_ERR(ar_ahb->cmd_clk));
- return ar_ahb->cmd_clk ? PTR_ERR(ar_ahb->cmd_clk) : -ENODEV;
+ return PTR_ERR(ar_ahb->cmd_clk);
}
ar_ahb->ref_clk = devm_clk_get(dev, "wifi_wcss_ref");
- if (IS_ERR_OR_NULL(ar_ahb->ref_clk)) {
+ if (IS_ERR(ar_ahb->ref_clk)) {
ath10k_err(ar, "failed to get ref clk: %ld\n",
PTR_ERR(ar_ahb->ref_clk));
- return ar_ahb->ref_clk ? PTR_ERR(ar_ahb->ref_clk) : -ENODEV;
+ return PTR_ERR(ar_ahb->ref_clk);
}
ar_ahb->rtc_clk = devm_clk_get(dev, "wifi_wcss_rtc");
- if (IS_ERR_OR_NULL(ar_ahb->rtc_clk)) {
+ if (IS_ERR(ar_ahb->rtc_clk)) {
ath10k_err(ar, "failed to get rtc clk: %ld\n",
PTR_ERR(ar_ahb->rtc_clk));
- return ar_ahb->rtc_clk ? PTR_ERR(ar_ahb->rtc_clk) : -ENODEV;
+ return PTR_ERR(ar_ahb->rtc_clk);
}
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: mac80211: skip BSS_CHANGED_TXPOWER notification for monitor mode
From: Lachlan Hodges @ 2026-02-07 8:23 UTC (permalink / raw)
To: Dhyan K Prajapati
Cc: Johannes Berg, linux-wireless, linux-kernel, Dhyan K Prajapati
In-Reply-To: <20260207050035.6720-1-dhyan19022009@gmail.com>
Hi,
On Sat, Feb 07, 2026 at 10:30:35AM +0530, Dhyan K Prajapati wrote:
> From: Dhyan K Prajapati <dhyaan19022009@gmail.com>
>
> Monitor mode interfaces don't maintain BSS context. The BSS_CHANGED_TXPOWER notification
> indicates transmit power constrains recieved from an associated access point which isn't really
> applicable to monitor mode as it does not associate with any BSS
>
> after a commit back in july 2025,("wifi: mac80211: fix WARN_ON for monitor mode
> on some devices") monitor interfaces with WANT_MONITOR_VIF began recieving link
> change notifications during ieee_add_virtual_monitor(), when ieee_link_use_channel()
> assigns a channel context it triggers ieee_recalc_power() which sends BSS_CHANGED_TXPOWER
> notifications to driver, driver using legacy bss_info_changed callbeack recieve
> link->conf as the bss_conf parameter for monitor mode that points to vif.bss_conf which is not fully initialised
> in monitor interfaces, so drivers like iwldvm dereference null and crash
> since BSS_CHANGED_TXPOWER notifications are meaningless for monitor mode, we can skip
> the notification entirely,monitor mode transmit power remains configurable via
> nl80211
You should try and limit the line length of the commit message to
72 lines. Also, there's a few spelling errors - these can be caught
by running checkpatch [1] on your patch before submission (and you
should run this everytime before any patch you submit). Also it
looks like the 'Signed-off-by' tag doesn't match.
> Hardware: Dell Latitude E6430
> Device: Intel Centrino Advanced-N 6205 [Taylor Peak]
>
> Crash trace:
> BUG: kernel NULL pointer dereference at 0000000000000000
> RIP: iwlagn_bss_info_changed+0x19d/0x640 [iwldvm]
> Call Trace:
> drv_link_info_changed+0x2b5/0x2c0
> ieee80211_link_info_change_notify+0x13d/0x160
> __ieee80211_recalc_txpower+0x44/0xd0
> ieee80211_recalc_txpower+0x5c/0x60
> ieee80211_assign_link_chanctx+0x182/0x410
> ieee80211_link_use_channel+0x413/0x450
> ieee80211_add_virtual_monitor+0x17c/0x2b0
>
> Tested-by: Dhyan K Prajapati <dhyan19022009@gmail.com>
> Signed-off-by: Dhyan K Prajapati <dhyan19022009@gmail.com>
If this is indeed a bug (I haven't really reviewed the change in
depth), you should find the commit you are fixing (assuming the
one mentioned above) and format as follows:
Fixes: c57e5b9819df ("wifi: mac80211: fix WARN_ON for monitor mode on some devices")
Then place it above the Tested-by tags and so on [2]. Don't worry
about the length of the fixes tag if the commit message is too long,
just keep it in its entirety. You can add this to your git config to
easily format this line which I stole from Johannes:
[...]
[pretty]
fixes = Fixes: %h (\"%s\")
[alias]
fixes = show -q --format=fixes
[...]
Then just run, for example "git fixes c57e5b9819df" to generate the
correct format for your patch. Additionally you should target the
'wireless' if it's fixing a bug such that it can get into the next
RC. You can do so by prefixing the subject like so:
[PATCH wireless] wifi: mac80211: skip BSS_...
> if (__ieee80211_recalc_txpower(link) ||
> - (update_bss && ieee80211_sdata_running(link->sdata)))
> + (update_bss && ieee80211_sdata_running(link->sdata))) {
> + if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
> + return;
> +
Could you just include that statement inside the original if?
lachlan
[1] https://docs.kernel.org/dev-tools/checkpatch.html
[2] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
^ permalink raw reply
* Re: New warning `ath10k_pci 0000:3a:00.0: not found station for peer stats`
From: Paul Menzel @ 2026-02-07 5:55 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath10k, Baochen Qiang
In-Reply-To: <57671b89-ec9f-4e6c-992c-45eb8e75929c@molgen.mpg.de>
[Cc: +Baochen]
Dear Linux folks,
Am 19.01.26 um 17:41 schrieb Paul Menzel:
> Since January 10th, I have started seeing the warning below in my Linux
> logs, that reach back to September 24th, 2025:
>
> [ 37.108902] ath10k_pci 0000:3a:00.0: not found station for peer stats
> [ 37.108906] ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>
> It started appearing with 6.19.0-rc4-00282-gb6151c4e60e5, the version
> running before is 6.19.0-rc4-00003-g3609fa95fb0f, but I do not see
> anything related in the commit list:
>
> git log --oneline 3609fa95fb0f...b6151c4e60e5
>
> The warning log from `drivers/net/wireless/ath/ath10k/wmi-tlv.c` has
> also been there since 2021.
>
> Do you have an idea? Please find the output of `dmesg` attached.
Looking through the commit list from above again, commit a203dbeeca15
(wifi: mac80211: collect station statistics earlier when disconnect)
probably introduced the new behavior.
Kind regards,
Paul
^ 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