* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Rameshkumar Sundaram @ 2026-05-14 4:54 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, rameshkumar.sundaram
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260508103202.456865-1-jtornosm@redhat.com>
On 5/8/2026 4:01 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
>
>> What is the exact failure? Do you see any driver error logs when it occurs?
> No error log, just the warning.
>
>> Got it. I was just thinking along with the proposed fix — whether we
>> might also need to handle the sequencing on QMI failure.
>> In other words, do you think the issue(double free) would still be
>> reproducible if we include a change like below ?
> Yes, I think so and in addition the code is more robust.
>
I agree that setting tx_status to NULL makes ath11k_dp_free() more
defensive, and it matches the ath12k fix.
However, i am still wondering how the second ath11k_dp_free() is reached
if ATH11K_FLAG_QMI_FAIL is set.
In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
ath11k_pci_remove()
ath11k_core_deinit()
ath11k_core_soc_destroy()
ath11k_dp_free()
should not run.
So if the double free is still reproducible with QMI_FAIL set (with the
change i proposed), either the flag is not actually set in this failure
case, or there is another path calling ath11k_dp_free() ?
--
Ramesh
^ permalink raw reply
* [PATCH] wifi: ath11k: clear shared SRNG pointer state on restart
From: Kyle Farnung via B4 Relay @ 2026-05-14 4:52 UTC (permalink / raw)
To: Jeff Johnson, Muhammad Usama Anjum, Baochen Qiang
Cc: Jeff Johnson, linux-wireless, ath11k, linux-kernel, santiagorr,
stable, Kyle Farnung
From: Kyle Farnung <kfarnung@gmail.com>
LMAC rings reuse the shared rdp/wrp pointer buffers without going
through the normal SRNG hw-init path that zeros non-LMAC ring
pointers. After restart, ath11k_hal_srng_clear() can therefore hand
stale hp/tp state from the previous firmware instance back to the new
one.
Clear the shared pointer buffers while keeping the allocations in
place so restart still avoids reallocating SRNG DMA memory, but starts
with fresh ring-pointer state.
Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
Signed-off-by: Kyle Farnung <kfarnung@gmail.com>
---
This patch is the result of investigating suspend/resume failures on a
Lenovo ThinkPad P14s Gen 5 AMD with ath11k.
I originally proposed extending the existing ath11k PM quirk for this
platform, but after discussion in [1] and bisection the issue appears to
be a regression introduced by [2]. There is also a parallel report in [3]
that appears consistent with the same root cause. This patch keeps the
intended no-reallocation behavior from that change, but clears the
preserved shared SRNG pointer state so restart begins from a clean state.
Testing so far has been limited to local suspend/resume cycling on the
affected system. The issue was originally reproduced on v7.0.4, and the
patch was also built and tested on top of ath-current with repeated
suspend/resume cycles on a Lenovo ThinkPad P14s Gen 5 AMD.
[1] https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
[2] 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132343
---
drivers/net/wireless/ath/ath11k/hal.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/hal.c b/drivers/net/wireless/ath/ath11k/hal.c
index e821e5a62c1c0..0c0aeb803018e 100644
--- a/drivers/net/wireless/ath/ath11k/hal.c
+++ b/drivers/net/wireless/ath/ath11k/hal.c
@@ -1387,14 +1387,21 @@ EXPORT_SYMBOL(ath11k_hal_srng_deinit);
void ath11k_hal_srng_clear(struct ath11k_base *ab)
{
- /* No need to memset rdp and wrp memory since each individual
- * segment would get cleared in ath11k_hal_srng_src_hw_init()
- * and ath11k_hal_srng_dst_hw_init().
+ /* Preserve the shared pointer buffers, but clear the previous
+ * firmware instance's hp/tp state before handing them back to FW.
+ * LMAC rings reuse this shared memory without going through the
+ * normal SRNG hw-init path that zeros non-LMAC ring pointers.
*/
memset(ab->hal.srng_list, 0,
sizeof(ab->hal.srng_list));
memset(ab->hal.shadow_reg_addr, 0,
sizeof(ab->hal.shadow_reg_addr));
+ if (ab->hal.rdp.vaddr)
+ memset(ab->hal.rdp.vaddr, 0,
+ sizeof(*ab->hal.rdp.vaddr) * HAL_SRNG_RING_ID_MAX);
+ if (ab->hal.wrp.vaddr)
+ memset(ab->hal.wrp.vaddr, 0,
+ sizeof(*ab->hal.wrp.vaddr) * HAL_SRNG_NUM_LMAC_RINGS);
ab->hal.avail_blk_resource = 0;
ab->hal.current_blk_index = 0;
ab->hal.num_shadow_reg_configured = 0;
---
base-commit: 54a5b38e4396530e5b2f12b54d3844e860ab6784
change-id: 20260513-kfarnung-ath11k-srng-clear-pointer-state-91d8ab07e5e2
Best regards,
--
Kyle Farnung <kfarnung@gmail.com>
^ permalink raw reply related
* [PATCH ath-current] wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
From: Baochen Qiang @ 2026-05-14 3:32 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel, Baochen Qiang
When connecting to an AP configured for EHT 20 MHz with a full EHT
MCS/NSS map (supporting MCS 0-13)
Supported EHT-MCS and NSS Set
EHT-MCS Map (BW <= 80MHz): 0x444444
.... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
.... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
.... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
.... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4
TX throughput is observed to be significantly lower than expected.
Investigation shows that TX rates are limited to EHT MCS 11, even though
the AP advertises support for EHT MCS 12/13.
The root cause is an incorrect parsing of the Supported EHT-MCS and NSS
Set element in ath12k_peer_assoc_h_eht().
IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20
MHz-Only Non-AP STAs.
IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all
other AP and non-AP STAs.
Currently the first format is parsed when the peer advertises no wider
HE channel width support, without considering whether it is an AP or a
non-AP STA. This is incorrect: the peer AP's capabilities must be parsed
using Figure 9-1074at even when it operates on 20 MHz only. Parsing it
as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero,
which is then passed to firmware, leading firmware to assume the peer
does not support MCS 13 and to limit TX rates at MCS 11.
Fix this by parsing the Figure 9-1074as format only when the peer is a
20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or
mesh point.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 6c95151e2e77 ("wifi: ath12k: Add EHT MCS/NSS rates to Peer Assoc")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index fbdfe6424fd7..42b04bd7f677 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -3446,7 +3446,9 @@ static void ath12k_peer_assoc_h_eht(struct ath12k *ar,
arg->peer_eht_mcs_count++;
fallthrough;
default:
- if (!(link_sta->he_cap.he_cap_elem.phy_cap_info[0] &
+ if ((vif->type == NL80211_IFTYPE_AP ||
+ vif->type == NL80211_IFTYPE_MESH_POINT) &&
+ !(link_sta->he_cap.he_cap_elem.phy_cap_info[0] &
IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL)) {
bw_20 = &eht_cap->eht_mcs_nss_supp.only_20mhz;
@@ -3475,7 +3477,9 @@ static void ath12k_peer_assoc_h_eht(struct ath12k *ar,
arg->punct_bitmap = ~arvif->punct_bitmap;
arg->eht_disable_mcs15 = link_conf->eht_disable_mcs15;
- if (!(link_sta->he_cap.he_cap_elem.phy_cap_info[0] &
+ if ((vif->type == NL80211_IFTYPE_AP ||
+ vif->type == NL80211_IFTYPE_MESH_POINT) &&
+ !(link_sta->he_cap.he_cap_elem.phy_cap_info[0] &
IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_MASK_ALL)) {
if (bw_20->rx_tx_mcs13_max_nss)
max_nss = max(max_nss, u8_get_bits(bw_20->rx_tx_mcs13_max_nss,
---
base-commit: 6a7693873b20680a3c33bae0c9f9cb3185f64ade
change-id: 20260414-ath12k-fix-20mhz-only-mcs-map-e79a5a9d6470
Best regards,
--
Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH v2] wifi: ath11k: fix txpower in ap mode for 6 Ghz
From: s.gottschall @ 2026-05-14 2:50 UTC (permalink / raw)
To: ath11k; +Cc: linux-wireless, Sebastian Gottschall
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
there is an issue which has been discovered a while ago while testing
which killed txpower to 0 dBm 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)
fixes: i74ef2d05ede63fd6416aa635aa8972dff901325f
(wifi: ath11k: use WMI_VDEV_SET_TPC_POWER_CMDID when EXT_TPC_REG_SUPPORT for 6 GHz)
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
---
drivers/net/wireless/ath/ath11k/mac.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index a48b6bf1f29a..0984c3981ee4 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -3497,13 +3497,13 @@ static int ath11k_mac_config_obss_pd(struct ath11k *ar,
return 0;
}
-static bool ath11k_mac_supports_station_tpc(struct ath11k *ar,
- struct ath11k_vif *arvif,
- const struct cfg80211_chan_def *chandef)
+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 +7647,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);
}
@@ -8155,6 +8155,7 @@ void ath11k_mac_fill_reg_tpc_info(struct ath11k *ar,
psd_power, tx_power;
s8 eirp_power = 0;
u16 start_freq, center_freq;
+ u8 reg_6ghz_power_mode;
chan = ctx->def.chan;
start_freq = ath11k_mac_get_6ghz_start_frequency(&ctx->def);
@@ -8311,8 +8312,14 @@ void ath11k_mac_fill_reg_tpc_info(struct ath11k *ar,
reg_tpc_info->num_pwr_levels = num_pwr_levels;
reg_tpc_info->is_psd_power = is_psd_power;
reg_tpc_info->eirp_power = eirp_power;
+ if (arvif->vdev_type == WMI_VDEV_TYPE_STA)
+ reg_6ghz_power_mode = vif->bss_conf.power_type;
+ else
+ /* For now, LPI is the only supported AP power mode */
+ reg_6ghz_power_mode = IEEE80211_REG_LPI_AP;
+
reg_tpc_info->ap_power_type =
- ath11k_reg_ap_pwr_convert(vif->bss_conf.power_type);
+ ath11k_reg_ap_pwr_convert(reg_6ghz_power_mode);
}
static void ath11k_mac_parse_tx_pwr_env(struct ath11k *ar,
--
2.51.0
^ permalink raw reply related
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Baochen Qiang @ 2026-05-14 1:55 UTC (permalink / raw)
To: Marcus Glocker
Cc: Maxim Storetvedt, ath12k, linux-wireless, jjohnson, kvalo,
Mark Kettenis
In-Reply-To: <fxrzvhcrbkugzfzmj6h5netczccav5hxfefzyns67t5jhakk5w@pp6addxjkdb2>
On 5/14/2026 4:47 AM, Marcus Glocker wrote:
> On Wed, May 13, 2026 at 01:26:50PM +0200, Marcus Glocker wrote:
>
>> On Wed, May 13, 2026 at 11:05:05AM +0800, Baochen Qiang wrote:
>>
>>>
>>>
>>> On 5/13/2026 3:59 AM, Marcus Glocker wrote:
>>>> 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
>>>
>>> the dmesg shows several WMI_INIT cmd instances which is not expected, because in normal
>>> operation this command should be sent only once.
>>>
>>> cat dmesg |grep -w 'sending WMI command 0x1'
>>> May 12 19:35:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>>> May 12 19:37:20 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>>> May 12 19:37:41 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>>> May 12 19:37:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>>> May 12 19:37:50 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>>>
>>> other than that I don't find any other clues.
>>
>> Yes, that is specific to the OpenBSD NIC framework. I've just tested
>> a quick hack with which the WMI_INIT cmd only gets issued once, but it
>> makes no difference to the firmware crash.
>>
>>>> enabled, plus the resulting RDDM binary after the firmware crash:
>>>
>>> how did you collect the RDDM binary, seems not in the right format, my tool can not parse
>>> it correctly. Looking into the binary, at least the magic 'ATH12K-FW-DUMP' is not present
>>> at the very beginning.
>>
>> It looks like ath12k wraps the raw RDDM dump in some ath12k firmware
>> dump structure, which we don't do with our driver. I did write a small
>> conversion program, trying to generate the dump which you expect. You
>> can find the converted dump file here:
>>
>> https://nazgul.ch/pub/qwz0-rddm.bin.out.gz
>>
>> I hope you can load that in to your tool.
>>
>>> And from which Linux version you take the ath12k codebase?
>>
>> Well, that is a good question. qwz (the ath12k OpenBSD driver), is
>> an initial clone of the qwx (the ath11k OpenBSD driver), which is
>> functional. On top of that we did changes, of which the recent ones
>> did sync missing functionality from the Linux ath12k driver. We did
>> already do a lot of comparison between qwz and the ath12k driver, but
>> we can't spot an obvious difference which could explain the firmware
>> crash. Obviously doesn't mean that there isn't a gap between qwz and
>> ath12k related to this issue which we don't see.
>>
>>>>
>>>> https://nazgul.ch/pub/qwz0-rddm.bin.gz
>>>>
>>>> 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
>>>
>
> Hi Baochen,
>
> I just want to quickly let you know that we did overcome the firmware
> crash. The culprit was that we did
>
> #define RX_BE_PADDING0_BYTES 80 -> instead of 8
>
> which did break the hal_rx_desc_wcn7850 struct:
>
> struct hal_rx_desc_wcn7850 {
> u64 msdu_end_tag; // offset 0
> struct rx_msdu_end_qcn9274 msdu_end; // offset 8
> u8 rx_padding0[N]; // <- the bug
> u64 mpdu_start_tag;
> struct rx_mpdu_start_qcn9274 mpdu_start;
> struct rx_pkt_hdr_tlv pkt_hdr_tlv;
> u8 msdu_payload[];
> };
>
> With that fixed, the firmware error is gone, and we can now receive
> and IP from DHCP. We're working on getting the TX path work next.
OK, good to see it gets fixed!
>
> Thanks and Regards,
> Marcus
^ permalink raw reply
* RE: [PATCH v3] wifi: rtw88: usb: fix memory leaks on USB write failures
From: Ping-Ke Shih @ 2026-05-14 1:14 UTC (permalink / raw)
To: luka.gejak@linux.dev, Kalle Valo
Cc: Sascha Hauer, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260513181008.13470-1-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> When rtw_usb_write_port() fails to submit a USB Request Block (URB)
> (e.g., due to device disconnect or ENOMEM), the completion callback is
> never executed.
>
> Currently, the driver ignores the return value of rtw_usb_write_port()
> in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
> functions rely on the completion callback to free the socket buffers
> (skbs) and the transaction control block (txcb), a submission failure
> results in:
> 1. A memory leak of the allocated skb in rtw_usb_write_data().
> 2. A memory leak of the txcb structure and all aggregated skbs in
> rtw_usb_tx_agg_skb().
>
> Fix this by checking the return value of rtw_usb_write_port(). If it
> fails, explicitly free the skb in rtw_usb_write_data(), and properly
> purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
>
> The issue was discovered in practice during device disconnect/reconnect
> scenarios and memory pressure conditions. Tested by verifying normal TX
> operation continues after the fix without regressions.
>
> Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
> Cc: stable@vger.kernel.org
> Tested-by: Luka Gejak <luka.gejak@linux.dev>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* RE: [PATCH v3] wifi: rtw88: increase TX report timeout to fix race condition
From: Ping-Ke Shih @ 2026-05-14 0:58 UTC (permalink / raw)
To: luka.gejak@linux.dev, Kalle Valo
Cc: Sascha Hauer, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260513180935.13289-1-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> The driver expects the firmware to report TX status within 500ms.
> However, a timeout can be triggered when the hardware performs
> background scans while under TX load. During these scans, the firmware
> stays off-channel for periods exceeding 500ms, delaying the delivery of
> TX reports back to the driver.
>
> When this occurs, the purge timer fires prematurely and drops the
> tracking skbs from the queue. This results in the host stack
> interpreting the missing status as packet loss, leading to TCP window
> collapse. In testing with iperf3, this causes throughput to drop from
> ~90 Mbps to near-zero for approximately 2 seconds until the connection
> recovers.
>
> Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
> sufficient to accommodate off-channel dwell time during full background
> scans, ensuring the purge timer only trips during genuine firmware
> lockups and preventing unnecessary TCP retransmission cycles.
>
> Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Since RTL8723DU is supported by the commit 87caeef032fc, I'd change Fixes
to below during getting merged.
Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support")
> Cc: stable@vger.kernel.org
> Tested-by: Luka Gejak <luka.gejak@linux.dev>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: mmc: Document support for nvmem-layout
From: Rob Herring @ 2026-05-13 22:42 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260507-block-as-nvmem-v2-1-bf17edd5134e@oss.qualcomm.com>
On Thu, May 07, 2026 at 05:24:36PM +0200, Loic Poulain wrote:
> Add support for an nvmem-layout subnode under an eMMC hardware
> partition. This allows the partition to be exposed as an NVMEM
> provider and its internal layout to be described. For example,
> an eMMC boot partition can be used to store device-specific
> information such as a WiFi MAC address.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/mmc/mmc-card.yaml | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> index a61d6c96df759102f9c1fbfd548b026a77921cae..b21426a49cf1d9aae5b4e8e447b5be11b08c96bf 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> @@ -40,6 +40,9 @@ patternProperties:
> contains:
> const: fixed-partitions
>
> + nvmem-layout:
> + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
> +
> required:
> - compatible
> - reg
> @@ -86,6 +89,27 @@ examples:
> read-only;
> };
> };
> +
> + partitions-boot2 {
Shouldn't this have a 'fixed-partitions' compatible? I'm not sure if
it's an oversight in the schema that 'compatible' is not required here.
It would be odd that compatible is optional, but if it is present, it
must contain 'fixed-partitions' compatible. A follow-up to fix that
would be great.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Rob
^ permalink raw reply
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Marcus Glocker @ 2026-05-13 20:47 UTC (permalink / raw)
To: Baochen Qiang
Cc: Maxim Storetvedt, ath12k, linux-wireless, jjohnson, kvalo,
Mark Kettenis
In-Reply-To: <cz6dbqafvulifyrefsxzwrlq5z5uojylphqkq5oydbn2bvcns5@bhj3hr2rvxhq>
On Wed, May 13, 2026 at 01:26:50PM +0200, Marcus Glocker wrote:
> On Wed, May 13, 2026 at 11:05:05AM +0800, Baochen Qiang wrote:
>
> >
> >
> > On 5/13/2026 3:59 AM, Marcus Glocker wrote:
> > > 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
> >
> > the dmesg shows several WMI_INIT cmd instances which is not expected, because in normal
> > operation this command should be sent only once.
> >
> > cat dmesg |grep -w 'sending WMI command 0x1'
> > May 12 19:35:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> > May 12 19:37:20 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> > May 12 19:37:41 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> > May 12 19:37:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> > May 12 19:37:50 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> >
> > other than that I don't find any other clues.
>
> Yes, that is specific to the OpenBSD NIC framework. I've just tested
> a quick hack with which the WMI_INIT cmd only gets issued once, but it
> makes no difference to the firmware crash.
>
> > > enabled, plus the resulting RDDM binary after the firmware crash:
> >
> > how did you collect the RDDM binary, seems not in the right format, my tool can not parse
> > it correctly. Looking into the binary, at least the magic 'ATH12K-FW-DUMP' is not present
> > at the very beginning.
>
> It looks like ath12k wraps the raw RDDM dump in some ath12k firmware
> dump structure, which we don't do with our driver. I did write a small
> conversion program, trying to generate the dump which you expect. You
> can find the converted dump file here:
>
> https://nazgul.ch/pub/qwz0-rddm.bin.out.gz
>
> I hope you can load that in to your tool.
>
> > And from which Linux version you take the ath12k codebase?
>
> Well, that is a good question. qwz (the ath12k OpenBSD driver), is
> an initial clone of the qwx (the ath11k OpenBSD driver), which is
> functional. On top of that we did changes, of which the recent ones
> did sync missing functionality from the Linux ath12k driver. We did
> already do a lot of comparison between qwz and the ath12k driver, but
> we can't spot an obvious difference which could explain the firmware
> crash. Obviously doesn't mean that there isn't a gap between qwz and
> ath12k related to this issue which we don't see.
>
> > >
> > > https://nazgul.ch/pub/qwz0-rddm.bin.gz
> > >
> > > 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
> >
Hi Baochen,
I just want to quickly let you know that we did overcome the firmware
crash. The culprit was that we did
#define RX_BE_PADDING0_BYTES 80 -> instead of 8
which did break the hal_rx_desc_wcn7850 struct:
struct hal_rx_desc_wcn7850 {
u64 msdu_end_tag; // offset 0
struct rx_msdu_end_qcn9274 msdu_end; // offset 8
u8 rx_padding0[N]; // <- the bug
u64 mpdu_start_tag;
struct rx_mpdu_start_qcn9274 mpdu_start;
struct rx_pkt_hdr_tlv pkt_hdr_tlv;
u8 msdu_payload[];
};
With that fixed, the firmware error is gone, and we can now receive
and IP from DHCP. We're working on getting the TX path work next.
Thanks and Regards,
Marcus
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: wireless: Add Intel Wi-Fi 7 BE200 PCIe adapter
From: Krzysztof Kozlowski @ 2026-05-13 18:23 UTC (permalink / raw)
To: Avinash Bhatt, devicetree, linux-wireless
Cc: robh, krzk+dt, conor+dt, johannes, miriam.rachel.korenblit,
linux-kernel, kobi.guetta, emmanuel.grumbach
In-Reply-To: <20260513060531.8130-2-avinash.bhatt@intel.com>
On 13/05/2026 08:05, Avinash Bhatt wrote:
> + bit 23: Paraguay
> + bit 24: Vietnam
> + bit 25: India
> + bit 27: enable VLP active scan, SoftAP, and P2P-GO in Japan
> + bit 29: enable VLP mode per intel,uats country table
> + bit 30: enable AFC mode per intel,uats country table
> + bit 31: use intel,uats country table for LPI (0 = group mode)
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> + intel,regulatory-special:
> + description: |
> + Special regulatory configuration flags.
> +
> + bit 4: enable Australia UHB band extension
> + bit 5: Bangladesh 6 GHz UHB enablement
I already NAK-ed this.
You took one week to reply to my comments but then gave me only one day
to disagree.
This is not how it works.
Implement previous comments. v2 discussion is still going, but this time
read netiquette and configure your email systems correctly.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: wireless: Add Intel Wi-Fi 7 BE200 PCIe adapter
From: Krzysztof Kozlowski @ 2026-05-13 18:20 UTC (permalink / raw)
To: Avinash Bhatt, devicetree, linux-wireless
Cc: robh, krzk+dt, conor+dt, johannes, miriam.rachel.korenblit,
linux-kernel, kobi.guetta, emmanuel.grumbach
In-Reply-To: <9801b98f-3806-435e-a2e8-80fab22fde0b@kernel.org>
On 13/05/2026 20:19, Krzysztof Kozlowski wrote:
> On 13/05/2026 08:05, Avinash Bhatt wrote:
>> The Intel Wi-Fi 7 BE200 is a discrete PCIe Wi-Fi adapter supporting
>> 802.11be with tri-band operation including the 6 GHz band.
>>
>> Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
>> ---
> You sent v2 on 4th of May.
>
> I replied one day later, on 4th of May.
4th -> 5th of May
>
> It took you entire week to reply to my comments, but then you do not
> wait for my replies one week. You send v3 the next day.
>
> DO NOT POST new versions while discussion is going.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: net: wireless: Add Intel Wi-Fi 7 BE200 PCIe adapter
From: Krzysztof Kozlowski @ 2026-05-13 18:19 UTC (permalink / raw)
To: Avinash Bhatt, devicetree, linux-wireless
Cc: robh, krzk+dt, conor+dt, johannes, miriam.rachel.korenblit,
linux-kernel, kobi.guetta, emmanuel.grumbach
In-Reply-To: <20260513060531.8130-2-avinash.bhatt@intel.com>
On 13/05/2026 08:05, Avinash Bhatt wrote:
> The Intel Wi-Fi 7 BE200 is a discrete PCIe Wi-Fi adapter supporting
> 802.11be with tri-band operation including the 6 GHz band.
>
> Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
> ---
You sent v2 on 4th of May.
I replied one day later, on 4th of May.
It took you entire week to reply to my comments, but then you do not
wait for my replies one week. You send v3 the next day.
DO NOT POST new versions while discussion is going.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] wifi: iwlwifi: add Device Tree hardware integration information
From: Krzysztof Kozlowski @ 2026-05-13 18:18 UTC (permalink / raw)
To: Bhatt, Avinash
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: <BL1PR11MB5954BCE96853D1F299E4DEACE0392@BL1PR11MB5954.namprd11.prod.outlook.com>
On 12/05/2026 12:07, Bhatt, Avinash wrote:
> 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
Do not top post.
If you are not willing to post DTS, then you are not helping us to
understand the completeness of this binding and hardware description.
IOW, the bigger picture is missing, so IMO I would remove most of the
properties.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] wifi: iwlwifi: dt: add Device Tree BIOS configuration infrastructure
From: Krzysztof Kozlowski @ 2026-05-13 18:16 UTC (permalink / raw)
To: Bhatt, Avinash
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: <BL1PR11MB595490A72F8319FBB23194F1E0392@BL1PR11MB5954.namprd11.prod.outlook.com>
On 12/05/2026 12:03, Bhatt, Avinash wrote:
> 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.
>
What is this style of answering? Am I replying now to my own email?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] wifi: rtw88: usb: fix memory leaks on USB write failures
From: luka.gejak @ 2026-05-13 18:10 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo
Cc: Sascha Hauer, linux-wireless, linux-kernel, Luka Gejak, stable
From: Luka Gejak <luka.gejak@linux.dev>
When rtw_usb_write_port() fails to submit a USB Request Block (URB)
(e.g., due to device disconnect or ENOMEM), the completion callback is
never executed.
Currently, the driver ignores the return value of rtw_usb_write_port()
in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
functions rely on the completion callback to free the socket buffers
(skbs) and the transaction control block (txcb), a submission failure
results in:
1. A memory leak of the allocated skb in rtw_usb_write_data().
2. A memory leak of the txcb structure and all aggregated skbs in
rtw_usb_tx_agg_skb().
Fix this by checking the return value of rtw_usb_write_port(). If it
fails, explicitly free the skb in rtw_usb_write_data(), and properly
purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
The issue was discovered in practice during device disconnect/reconnect
scenarios and memory pressure conditions. Tested by verifying normal TX
operation continues after the fix without regressions.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
Changes in v3:
- Updated the Fixes tag to the commit that introduced USB support.
Changes in v2:
- Use ret = rtw_usb_write_port(...); style, and check by next line (in
rtw_usb_tx_agg_skb)
- Remove unnecessary comment
- Use ieee80211_purge_tx_queue() instead of skb_queue_purge()
- Add testing details to commit message
drivers/net/wireless/realtek/rtw88/usb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
index 718940ebba31..1bb922cc2928 100644
--- a/drivers/net/wireless/realtek/rtw88/usb.c
+++ b/drivers/net/wireless/realtek/rtw88/usb.c
@@ -399,6 +399,7 @@ static bool rtw_usb_tx_agg_skb(struct rtw_usb *rtwusb, struct sk_buff_head *list
int agg_num = 0;
unsigned int align_next = 0;
u8 qsel;
+ int ret;
if (skb_queue_empty(list))
return false;
@@ -456,7 +457,13 @@ static bool rtw_usb_tx_agg_skb(struct rtw_usb *rtwusb, struct sk_buff_head *list
tx_desc = (struct rtw_tx_desc *)skb_head->data;
qsel = le32_get_bits(tx_desc->w1, RTW_TX_DESC_W1_QSEL);
- rtw_usb_write_port(rtwdev, qsel, skb_head, rtw_usb_write_port_tx_complete, txcb);
+ ret = rtw_usb_write_port(rtwdev, qsel, skb_head,
+ rtw_usb_write_port_tx_complete, txcb);
+ if (ret) {
+ ieee80211_purge_tx_queue(rtwdev->hw, &txcb->tx_ack_queue);
+ kfree(txcb);
+ return false;
+ }
return true;
}
@@ -518,8 +525,10 @@ static int rtw_usb_write_data(struct rtw_dev *rtwdev,
ret = rtw_usb_write_port(rtwdev, qsel, skb,
rtw_usb_write_port_complete, skb);
- if (unlikely(ret))
+ if (unlikely(ret)) {
rtw_err(rtwdev, "failed to do USB write, ret=%d\n", ret);
+ dev_kfree_skb_any(skb);
+ }
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v3] wifi: rtw88: increase TX report timeout to fix race condition
From: luka.gejak @ 2026-05-13 18:09 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo
Cc: Sascha Hauer, linux-wireless, linux-kernel, Luka Gejak, stable
From: Luka Gejak <luka.gejak@linux.dev>
The driver expects the firmware to report TX status within 500ms.
However, a timeout can be triggered when the hardware performs
background scans while under TX load. During these scans, the firmware
stays off-channel for periods exceeding 500ms, delaying the delivery of
TX reports back to the driver.
When this occurs, the purge timer fires prematurely and drops the
tracking skbs from the queue. This results in the host stack
interpreting the missing status as packet loss, leading to TCP window
collapse. In testing with iperf3, this causes throughput to drop from
~90 Mbps to near-zero for approximately 2 seconds until the connection
recovers.
Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
sufficient to accommodate off-channel dwell time during full background
scans, ensuring the purge timer only trips during genuine firmware
lockups and preventing unnecessary TCP retransmission cycles.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support")
Cc: stable@vger.kernel.org
Tested-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
---
Changes in v3:
-Declared timeout with RTW_TX_PROBE_TIMEOUT as the default value and
removed the else branch.
-Updated the Fixes tag to the commit that introduced USB support.
Changes in v2:
-Isolated the change to RTL8723DU as requested by Ping-Ke
drivers/net/wireless/realtek/rtw88/tx.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
index 3106edb84fb4..a6e43314a4e9 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.c
+++ b/drivers/net/wireless/realtek/rtw88/tx.c
@@ -196,6 +196,7 @@ void rtw_tx_report_purge_timer(struct timer_list *t)
void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn)
{
struct rtw_tx_report *tx_report = &rtwdev->tx_report;
+ unsigned long timeout = RTW_TX_PROBE_TIMEOUT;
unsigned long flags;
u8 *drv_data;
@@ -207,7 +208,11 @@ void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn)
__skb_queue_tail(&tx_report->queue, skb);
spin_unlock_irqrestore(&tx_report->q_lock, flags);
- mod_timer(&tx_report->purge_timer, jiffies + RTW_TX_PROBE_TIMEOUT);
+ if (rtwdev->chip->id == RTW_CHIP_TYPE_8723D &&
+ rtwdev->hci.type == RTW_HCI_TYPE_USB)
+ timeout = msecs_to_jiffies(2500);
+
+ mod_timer(&tx_report->purge_timer, jiffies + timeout);
}
EXPORT_SYMBOL(rtw_tx_report_enqueue);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
From: Santiago Ruano Rincón @ 2026-05-13 17:57 UTC (permalink / raw)
To: Kyle Farnung
Cc: Jeff Johnson, Jeff Johnson, linux-wireless, ath11k, linux-kernel,
kfarnung, Mark Pearson, koike
In-Reply-To: <CAOPSVF29ofKi8fpmJxuq9F5uQXHe4RrFvGb2V-odGMNA77NWXw@mail.gmail.com>
El 12/05/26 a las 20:30, Kyle Farnung escribió:
> On Tue, May 12, 2026 at 5:03 PM Jeff Johnson
> <jeff.johnson@oss.qualcomm.com> wrote:
> >
> > On 5/6/2026 12:54 PM, Santiago Ruano Rincón wrote:
> > > Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
> > > table") added some Lenovo platform IDs to the quirk table to address a
> > > wakeup from suspend issue [1]. However, at least P14s Gen 5 AMD, as
> > > reported by Kyle Farnung [2], and P14s Gen 3 AMD are missing in the
> > > table. This commit adds the two corresponding Lenovo version IDs for
> > > each.
> > >
> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> > > [2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
> > >
> > > Tested-on: P14s G3 AMD running 7.0.3.
> > >
> > > Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
> > > Co-authored-by: Kyle Farnung <kfarnung@gmail.com>
> >
> > This is not a standard Linux kernel commit tag.
> > Co-developed-by: could be used, but I'd need a Signed-off-by: from Kyle
> >
> > Kyle, if you'd like these added please reply with both a Co-developed-by and
> > a Signed-off-by tag
>
> I re-tested the bug behavior on the v7.0.4 tag and found that I'm not able
> to reproduce it on my device. I put the device to sleep and then unplugged
> and replugged power; it never woke up until I intentionally woke it.
>
> Based on discussion in [3], I narrowed my issue with wi-fi disassociation
> on wake to a suspect commit [4]. I'm developing a patch that clears the rdp
> and wrp buffers during wake to clear out any stale state in the LMAC rings.
> I'll submit that once I'm done testing it.
>
> Santiago: Are you seeing the sleep/wake bug from [1] or something similar
> to what I was seeing around disconnections on wake?
I was seeing wifi issues after wake-up, including disassociations, as
described at https://bugs.debian.org/1132343.
>
> [3] https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
> [4] 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and
> re-initialize again")
>
> >
> > I can apply these fixes when I process the patch in my tree.
> >
> > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
> >
> > > Signed-off-by: Santiago Ruano Rincón <santiagorr@riseup.net>
> > > ---
> > > Changes in v2:
> > > - Merged the Lenovo P14s G5 AMD #1 and #2 related changes proposed by
> > > Kyle Farnung in
> > > https://lore.kernel.org/all/20260330-p14s-pm-quirk-v2-1-ef18ce07996b@gmail.com/
> > > - Added Kyle Farnung as Co-author of the commit
> > > - Added the second ID of Lenovo P14s G3 AMD, and adapt the comments
> > > accordingly
> > > - v1: https://lore.kernel.org/ath11k/20260423211458.458911-1-santiagorr@riseup.net/
> > > ---
> > > drivers/net/wireless/ath/ath11k/core.c | 28 ++++++++++++++++++++++++++
> > > 1 file changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> > > index 3f6f4db5b7ee..c1ce0a11af44 100644
> > > --- a/drivers/net/wireless/ath/ath11k/core.c
> > > +++ b/drivers/net/wireless/ath/ath11k/core.c
> > > @@ -957,6 +957,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
> > > DMI_MATCH(DMI_PRODUCT_NAME, "21K4"),
> > > },
> > > },
> > > + {
> > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > + .matches = { /* P14s G3 AMD #1 */
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "21J5"),
> > > + },
> > > + },
> > > + {
> > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > + .matches = { /* P14s G3 AMD #2 */
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "21J6"),
> > > + },
> > > + },
> > > {
> > > .driver_data = (void *)ATH11K_PM_WOW,
> > > .matches = { /* P14s G4 AMD #1 */
> > > @@ -971,6 +985,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
> > > DMI_MATCH(DMI_PRODUCT_NAME, "21K6"),
> > > },
> > > },
> > > + {
> > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > + .matches = { /* P14s G5 AMD #1 */
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
> > > + },
> > > + },
> > > + {
> > > + .driver_data = (void *)ATH11K_PM_WOW,
> > > + .matches = { /* P14s G5 AMD #2 */
> > > + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "21MF"),
> > > + },
> > > + },
> > > {
> > > .driver_data = (void *)ATH11K_PM_WOW,
> > > .matches = { /* T16 G2 AMD #1 */
> >
^ permalink raw reply
* [PATCH wireless] wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed
From: Miri Korenblit @ 2026-05-13 15:26 UTC (permalink / raw)
To: linux-wireless
In case reconfiguration of NAN fails, we call
ieee80211_handle_reconfig_failure, that marks all interfaces as not in
the driver.
Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces
is called to destroy all the interfaces.
If we have any other interface but the NAN one, for example a BSS
station, then when its state (links, stations) will be removed, we
won't tell the driver about this, because we will think that the
interfaces are not in the driver, and then drivers might remain with
dangling pointers to objects like stations and links (at least for
iwlwifi this is the case).
ieee80211_handle_reconfig_failure is meant to be called after we cleaned
up the state in the driver, there is no reason to call it for NAN
reconfiguration failure.
Fix the code to just warn in such a case, as we do in other error paths
in reconfig where it is too complicated to rewind.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/util.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 2529b01e2cd5..dd2ba0fa0331 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2200,11 +2200,7 @@ int ieee80211_reconfig(struct ieee80211_local *local)
}
break;
case NL80211_IFTYPE_NAN:
- res = ieee80211_reconfig_nan(sdata);
- if (res < 0) {
- ieee80211_handle_reconfig_failure(local);
- return res;
- }
+ WARN_ON(ieee80211_reconfig_nan(sdata));
break;
case NL80211_IFTYPE_NAN_DATA:
case NL80211_IFTYPE_AP_VLAN:
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next] wifi: mac80211: Allow per station GTK for NAN Data interfaces
From: Miri Korenblit @ 2026-05-13 14:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Ilan Peer, Johannes Berg, Miriam Rachel Korenblit
From: Ilan Peer <ilan.peer@intel.com>
The WiFi Aware specification (v4.0) requires that NAN devices that
support security would also support per station GTK. Thus, allow
per station GTK installation to the driver on NAN Data interfaces.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
tested: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/key.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 4b8965633df3..3030bd40bca0 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -6,7 +6,7 @@
* Copyright 2007-2008 Johannes Berg <johannes@sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
* Copyright 2015-2017 Intel Deutschland GmbH
- * Copyright 2018-2020, 2022-2025 Intel Corporation
+ * Copyright 2018-2020, 2022-2026 Intel Corporation
*/
#include <crypto/utils.h>
@@ -150,11 +150,14 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
sta = key->sta;
/*
- * If this is a per-STA GTK, check if it
- * is supported; if not, return.
+ * Allow installation of a per-STA GTK if per-STA GTK is supported
+ * by the driver or the interface is a NAN Data interface (as
+ * per-station GTKs are required to be supported if secure NAN is
+ * supported).
*/
if (sta && !(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE) &&
- !ieee80211_hw_check(&key->local->hw, SUPPORTS_PER_STA_GTK))
+ !(ieee80211_hw_check(&key->local->hw, SUPPORTS_PER_STA_GTK) ||
+ sdata->vif.type == NL80211_IFTYPE_NAN_DATA))
goto out_unsupported;
if (sta && !sta->uploaded)
--
2.34.1
^ permalink raw reply related
* [PATCH wireless] wifi: mac80211: don't override max_amsdu_subframes
From: Miri Korenblit @ 2026-05-13 14:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach, Johannes Berg
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In client mode, the extended capabilities are handled by the kernel
looking at the association frame. When the supplicant installs the keys
it calls sta_apply_parameters and it doesn't include the extended
capabilities since those can't change after association.
As a result, we overrode the max_amsdu_subframes that we set after
association.
Check that the ext_capa coming from the user space is valid before
looking at it. If the ext_capa is NULL, it really means that the
extended capabilities are not changed (as opposed to cleared).
The default value for max_amsdu_subframes is 0, which means there is no
limit. This value is valid and in case the association response frame
does not have extended capabilities, this is the value we should use.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221079
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/cfg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7b77d57c9f96..f9ee9947a94d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2344,8 +2344,9 @@ static int sta_apply_parameters(struct ieee80211_local *local,
sta->sta.max_sp = params->max_sp;
}
- ieee80211_sta_set_max_amsdu_subframes(sta, params->ext_capab,
- params->ext_capab_len);
+ if (params->ext_capab)
+ ieee80211_sta_set_max_amsdu_subframes(sta, params->ext_capab,
+ params->ext_capab_len);
/*
* cfg80211 validates this (1-2007) and allows setting the AID
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 00/16] firmware: qcom: Add OP-TEE PAS service support
From: Sumit Garg @ 2026-05-13 13:44 UTC (permalink / raw)
To: andersson, konradybcio
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
dikshita.agarwal, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260504130603.1474043-1-sumit.garg@kernel.org>
Hi Bjorn,
Just a gentle reminder for any further reviews for this series. If not
then please help to pick it up this merge window since we have got acks
from corresponding subsystem maintainer too. There were few minor comments
addressed by following diff on top of this series. Let me know if you
need a new version for that or can they be folded in when you pick this
series?
diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
index 025308adf553..bc6c42f2b3c6 100644
--- a/drivers/firmware/qcom/qcom_pas.c
+++ b/drivers/firmware/qcom/qcom_pas.c
@@ -181,7 +181,7 @@ EXPORT_SYMBOL_GPL(qcom_pas_auth_and_reset);
* qcom_pas_prepare_and_auth_reset() - Prepare, authenticate, and reset the
* remote processor
*
- * @ctx: Context saved during call to qcom_scm_pas_context_init()
+ * @ctx: Context saved during call to devm_qcom_pas_context_alloc()
*
* This function performs the necessary steps to prepare a PAS subsystem,
* authenticate it using the provided metadata, and initiate a reset sequence.
diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
index c5ba91e6f95e..dff7fa7027c5 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.c
+++ b/drivers/net/wireless/ath/ath12k/ahb.c
@@ -488,7 +488,7 @@ static void ath12k_ahb_power_down(struct ath12k_base *ab, bool is_suspend)
ret = qcom_pas_shutdown(pasid);
if (ret)
ath12k_err(ab, "pas shutdown failed for userPD%d: %d\n",
- ab_ahb->userpd_id);
+ ab_ahb->userpd_id, ret);
}
}
-Sumit
On Mon, May 04, 2026 at 06:35:47PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 board with lemans
> EVK board being the next target. In addition to that WIN/IPQ targets
> planning to use OP-TEE will use this service too. Surely the backwards
> compatibility is maintained and tested for SCM backend.
>
> Note that kernel PAS service support while running in EL2 is at parity
> among OP-TEE vs QTEE. Especially the media (venus/iris) support depends
> on proper IOMMU support being worked out on the PAS client end.
>
> Patch summary:
> - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
> only allow UEFI and Linux to boot in EL2.
> - Patch #2: adds generic PAS service.
> - Patch #3: migrates SCM backend to generic PAS service.
> - Patch #4: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #5-#14: migrates all client drivers to generic PAS service.
> - Patch #15: drops legacy PAS SCM exported APIs.
>
> The patch-set is based on v7.1-rc1 tag and can be found in git tree here
> [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged)
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v5
>
> ---
> Changes in v5:
> - Incorporated misc. comments from Mukesh.
> - Split up patch #11 into 2 to add an independent commit for passing
> proper PAS ID to set_remote_state API.
> - Picked up tags.
>
> Changes in v4:
> - Incorporate misc. comments on patch #4.
> - Picked up an ack for patch #10.
> - Clarify in cover letter about state of media support.
>
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Mukesh Ojha (1):
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> Sumit Garg (15):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> soc: qcom: mdtloader: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> media: qcom: Pass proper PAS ID to set_remote_state API
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
> drivers/firmware/qcom/Kconfig | 19 +
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 25 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 8 +-
> drivers/remoteproc/Kconfig | 4 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 28 files changed, 1117 insertions(+), 318 deletions(-)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
> --
> 2.51.0
>
>
^ permalink raw reply related
* Re: [REGRESSION] iwlwifi 8265 firmware ADVANCED_SYSASSERT in PHY_CONTEXT_CMD on roam (v7.0.3..v7.0.5)
From: Branislav Klocok @ 2026-05-13 11:40 UTC (permalink / raw)
To: Johannes Berg, regressions; +Cc: linux-wireless
In-Reply-To: <34084815328ea9ea00893e9aa46962d369d213e3.camel@sipsolutions.net>
[-- Attachment #1.1: Type: text/plain, Size: 2725 bytes --]
Hi Johannes,
Thanks for the quick check. I dug a bit further; the v7.0.3..v7.0.5
window is what I empirically see (clean -> crashing on every
controller-driven roam), but the cause likely sits outside iwlwifi as
you suggested.
What I can confirm from the openSUSE Tumbleweed packaging side:
- Between kernel-default-7.0.3-1.1 (installed 2026-05-08 21:45) and
7.0.5-1.1 (2026-05-10 21:25), only the kernel package changed.
kernel-firmware-intel was bumped to 20260505-1.1 in the same transaction
as 7.0.3 on 2026-05-08 and stayed unchanged across the 7.0.5 install
(8265 ucode 36.c8e8e144.0 is identical in both dmesg banners).
NetworkManager 1.54.3-3.4 and wpa_supplicant 2.11-6.3 were last touched
on 2026-05-04, also unchanged across this window. Userspace and firmware
blob can be ruled out as the trigger.
- The only iwlwifi-touching SUSE patch added between the 7.0.3 and 7.0.5
source packages is iwlwifi-declare-missing-firmware-files.patch in
7.0.4, which is metadata-only (it just adds MODULE_FIRMWARE() entries).
The rest of the diff is plain stable v7.0.3..v7.0.5.
- Caveat on my "7.0.3 worked" claim: it is based on a short boot into
7.0.3 on 2026-05-11 before booting 7.0.5; I will re-test 7.0.3 over a
longer window with forced roams to be sure.
Crash itself: ADVANCED_SYSASSERT (0x000014FD) + NMI_INTERRUPT_LMAC_FATAL
(0x70) on PHY_CONTEXT_CMD during nl80211_authenticate. ~87 % of
controller-driven roams trigger it (14/16 observed); cascading restart
loops (6x in 23 s) on bad days. NM powersave=2 (CAM) does not suppress
it. Full journal at https://bugzilla.kernel.org/show_bug.cgi?id=221512
(attachment 310106).
A couple of questions, if you have a moment:
1. Is there an iwlmvm debug knob you'd like enabled on the next
reproduction (iwlwifi.debug=, devcoredump, fw_dbg_collect) to capture
more on what PHY_CONTEXT_CMD is hitting?
2. Given iwlwifi/mac80211 is unchanged, would you point at a tighter
candidate area in v7.0.3..v7.0.5 (PCI PM, firmware loader, scheduler)
before I attempt a bisect across the full tree?
*-- *
S pozdravom / Best regards
*Branislav Klocok *
*generálny riaditeľ / general director *
* OFZ, a.s.*
Mobil: *+421 908 703 366*
Tel: *+421 43 5804 488 *
e-mail: **branislav.klocok@ofz.sk* <mailto:branislav.klocok@ofz.sk> *
web: **www.ofz.company* <http://www.ofz.company> *
ofz logo
Dňa 13. 5. 2026 o 12:41 Johannes Berg napísal(a):
> On Wed, 2026-05-13 at 12:35 +0200, Branislav Klocok wrote:
>> #regzbot introduced: v7.0.3..v7.0.5
> That cannot be right, there are no patches for wifi between those except
> a handful in drivers you're not running.
>
> johannes
[-- Attachment #1.2.1: Type: text/html, Size: 5836 bytes --]
[-- Attachment #1.2.2: FWbyySErjYKwOByv.png --]
[-- Type: image/png, Size: 4675 bytes --]
[-- Attachment #2: Kryptografický podpis S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4669 bytes --]
^ permalink raw reply
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Marcus Glocker @ 2026-05-13 11:26 UTC (permalink / raw)
To: Baochen Qiang
Cc: Maxim Storetvedt, ath12k, linux-wireless, jjohnson, kvalo,
Mark Kettenis
In-Reply-To: <92ace4b9-143e-4962-90fa-215a22e24796@oss.qualcomm.com>
On Wed, May 13, 2026 at 11:05:05AM +0800, Baochen Qiang wrote:
>
>
> On 5/13/2026 3:59 AM, Marcus Glocker wrote:
> > 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
>
> the dmesg shows several WMI_INIT cmd instances which is not expected, because in normal
> operation this command should be sent only once.
>
> cat dmesg |grep -w 'sending WMI command 0x1'
> May 12 19:35:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> May 12 19:37:20 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> May 12 19:37:41 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> May 12 19:37:46 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
> May 12 19:37:50 x1e /bsd: qwz_wmi_cmd_send_nowait: sending WMI command 0x1
>
> other than that I don't find any other clues.
Yes, that is specific to the OpenBSD NIC framework. I've just tested
a quick hack with which the WMI_INIT cmd only gets issued once, but it
makes no difference to the firmware crash.
> > enabled, plus the resulting RDDM binary after the firmware crash:
>
> how did you collect the RDDM binary, seems not in the right format, my tool can not parse
> it correctly. Looking into the binary, at least the magic 'ATH12K-FW-DUMP' is not present
> at the very beginning.
It looks like ath12k wraps the raw RDDM dump in some ath12k firmware
dump structure, which we don't do with our driver. I did write a small
conversion program, trying to generate the dump which you expect. You
can find the converted dump file here:
https://nazgul.ch/pub/qwz0-rddm.bin.out.gz
I hope you can load that in to your tool.
> And from which Linux version you take the ath12k codebase?
Well, that is a good question. qwz (the ath12k OpenBSD driver), is
an initial clone of the qwx (the ath11k OpenBSD driver), which is
functional. On top of that we did changes, of which the recent ones
did sync missing functionality from the Linux ath12k driver. We did
already do a lot of comparison between qwz and the ath12k driver, but
we can't spot an obvious difference which could explain the firmware
crash. Obviously doesn't mean that there isn't a gap between qwz and
ath12k related to this issue which we don't see.
> >
> > https://nazgul.ch/pub/qwz0-rddm.bin.gz
> >
> > 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
>
^ permalink raw reply
* Re: [REGRESSION] iwlwifi 8265 firmware ADVANCED_SYSASSERT in PHY_CONTEXT_CMD on roam (v7.0.3..v7.0.5)
From: Branislav Klocok @ 2026-05-13 10:58 UTC (permalink / raw)
To: regressions; +Cc: linux-wireless
In-Reply-To: <d2ffd82d-01cb-470e-bb02-70c163c61216@ofz.sk>
[-- Attachment #1.1: Type: text/plain, Size: 5235 bytes --]
Hi,
A few clarifications and additional data points after another working
day on 7.0.5 and after testing a recovery script — please take these
as a correction to the initial report:
1. The bug is INTERMITTENT on the roam path, not deterministic. My
initial phrasing ("every controller-initiated roam") was too strong.
Empirically across 16 observed roams: 14 crashed, 2 passed clean
(2026-05-13 11:19:23 and ~12:48). Crash probability ~87%, not 100%.
2. Some firmware crashes fire WITHOUT an immediately preceding
`disconnect from AP <a> for new auth to <b>` line in the kernel
journal: 2026-05-13 11:31:13, 12:04:28, 12:04:32, 12:18:18. These
may be background firmware events not surfaced via mac80211 mlme
tracing, or roam steering happening at a layer that mac80211 does
not log.
3. Manual `modprobe -r iwlmvm iwlwifi && modprobe iwlwifi` followed by
`nmcli connection up <SSID>` does recover the radio reliably in
~15 s when the cascading restart loop leaves Wi-Fi unusable. It
does NOT prevent future crashes (the next roam still asserts
firmware), but it's a working clean-up. Useful when the in-driver
SW reset loop fails to converge.
4. Open diagnostic question: whether the clean-roam cases differ in
any observable PHY parameter. The two clean events here both
landed on 2.4 GHz channel 9 (de:2c:6e:8f:59:ef and ce:2d:e0:be:4d:93)
but most crashing roams are also 2.4 GHz, so band/channel alone
isn't the discriminator. Auth state, BA/AMPDU state, or in-flight
command queue depth at the moment of binding are candidates.
These have also been posted as comments on the two Bugzilla trackers:
- https://bugzilla.kernel.org/show_bug.cgi?id=221512 (comment posted today)
- https://bugzilla.suse.com/show_bug.cgi?id=1264804 (comment posted today)
Still happy to test debug patches.
Thanks,
Branislav Klocok
*-- *
S pozdravom / Best regards
*Branislav Klocok *
*generálny riaditeľ / general director *
* OFZ, a.s.*
Mobil: *+421 908 703 366*
Tel: *+421 43 5804 488 *
e-mail: **branislav.klocok@ofz.sk* <mailto:branislav.klocok@ofz.sk> *
web: **www.ofz.company* <http://www.ofz.company> *
ofz logo
Dňa 13. 5. 2026 o 12:35 Branislav Klocok napísal(a):
> Hi,
>
> I would like to report a regression in stable kernel 7.0.x affecting
> iwlwifi on Intel Wireless-AC 8265. Bug filed at
> https://bugzilla.kernel.org/show_bug.cgi?id=221512
> (network-wireless-intel)
> and openSUSE Bugzilla https://bugzilla.suse.com/show_bug.cgi?id=1264804.
>
> #regzbot introduced: v7.0.3..v7.0.5
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=221512
> #regzbot link: https://bugzilla.suse.com/show_bug.cgi?id=1264804
>
> Summary: every controller-initiated roam between BSSIDs of the same
> enterprise ESSID triggers a firmware microcode assertion
> (`ADVANCED_SYSASSERT` / `NMI_INTERRUPT_LMAC_FATAL` / `FW error in SYNC
> CMD PHY_CONTEXT_CMD`). Driver SW-resets and re-associates in about
> 4 s, but some triggers send the driver into a cascading restart loop
> (observed 6 firmware errors in 23 s, twice in a single session).
> Identical hardware, firmware blob (`8265-36.ucode` v36.c8e8e144.0),
> network and userspace worked correctly on 7.0.3.
>
> I personally booted only 7.0.3 (good) and 7.0.5 (bad); 7.0.4 was
> installed but not run. The 7.0.5 stable changelog contains no
> iwlwifi/mac80211/cfg80211 commits, so the regression most likely sits
> in the 7.0.4 batch.
>
> Crash backtrace fragment:
>
> iwlwifi 0000:02:00.0: 0x000014FD | ADVANCED_SYSASSERT
> iwlwifi 0000:02:00.0: 0x00000070 | NMI_INTERRUPT_LMAC_FATAL
> iwlwifi 0000:02:00.0: FW error in SYNC CMD PHY_CONTEXT_CMD
> CPU: 2 UID: 0 PID: 1527 Comm: wpa_supplicant
> iwl_trans_pcie_send_hcmd+0x402/0x410 [iwlwifi]
> iwl_trans_send_cmd+0x3e/0xa0 [iwlwifi]
> ? nl80211_authenticate+0x373/0x400 [cfg80211]
> nl80211_authenticate+0x38d/0x400 [cfg80211]
> iwlwifi 0000:02:00.0: PHY ctxt cmd error. ret=-5
>
> Workarounds tested and rejected:
> - `802-11-wireless.powersave=2` (CAM) — does not prevent the crash;
> client still receives steering and firmware still asserts on
> `PHY_CONTEXT_CMD`.
> - `modprobe -r iwlmvm iwlwifi && modprobe iwlwifi` — temporary
> recovery only; next roam reproduces the crash.
>
> The only known mitigation is staying on 7.0.3 or avoiding networks
> with controller-driven band/load steering.
>
> I am happy to test patches against the affected hardware and network.
> Full filtered kernel log (3329 lines, both cascading restart loops)
> is attached to the bugzilla.kernel.org bug.
>
> Hardware:
> - Intel Wireless-AC 8265 [8086:24fd] rev 78, subsys [8086:0010]
> - ThinkPad, openSUSE Tumbleweed (rolling) snapshot 20260509
> - kernel-firmware-iwlwifi 20260331-1.1
> - NetworkManager 1.54.3-3.4, wpa_supplicant 2.11-6.3
>
> Thanks,
> Branislav Klocok
> *-- *
> S pozdravom / Best regards
> *Branislav Klocok *
> *generálny riaditeľ / general director *
>
>
> * OFZ, a.s.*
> Mobil: *+421 908 703 366*
> Tel: *+421 43 5804 488 *
> e-mail: **branislav.klocok@ofz.sk* <mailto:branislav.klocok@ofz.sk> *
> web: **www.ofz.company* <http://www.ofz.company> *
>
>
> ofz logo
>
[-- Attachment #1.2.1: Type: text/html, Size: 11935 bytes --]
[-- Attachment #1.2.2: utpDdaMgmKCI02E0.png --]
[-- Type: image/png, Size: 4675 bytes --]
[-- Attachment #1.2.3: WdtYKUGW07EU0N07.png --]
[-- Type: image/png, Size: 4675 bytes --]
[-- Attachment #2: Kryptografický podpis S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4669 bytes --]
^ permalink raw reply
* Re: [REGRESSION] iwlwifi 8265 firmware ADVANCED_SYSASSERT in PHY_CONTEXT_CMD on roam (v7.0.3..v7.0.5)
From: Johannes Berg @ 2026-05-13 10:41 UTC (permalink / raw)
To: Branislav Klocok, regressions; +Cc: linux-wireless
In-Reply-To: <d2ffd82d-01cb-470e-bb02-70c163c61216@ofz.sk>
On Wed, 2026-05-13 at 12:35 +0200, Branislav Klocok wrote:
> #regzbot introduced: v7.0.3..v7.0.5
That cannot be right, there are no patches for wifi between those except
a handful in drivers you're not running.
johannes
^ 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