* Re: [PATCH rtw-next v3] wifi: rtw89: check return values in rtw89_ops_start_ap()
From: Ping-Ke Shih @ 2026-07-03 3:51 UTC (permalink / raw)
To: Dmitry Morgun, Ping-Ke Shih
Cc: Dmitry Morgun, linux-wireless, linux-kernel, lvc-project
In-Reply-To: <20260629094452.8709-1-d.morgun@ispras.ru>
Dmitry Morgun <d.morgun@ispras.ru> wrote:
> Several functions called in rtw89_ops_start_ap() may fail to allocate
> skb or fail to send H2C command to firmware, returning -ENOMEM or an
> error code. Their return values are ignored, so subsequent commands
> are executed with incorrect state.
>
> Check the return values and propagate errors.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: a52e4f2ce0f5 ("wifi: rtw89: implement ieee80211_ops::start_ap and stop_ap")
> Signed-off-by: Dmitry Morgun <d.morgun@ispras.ru>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
a8cddb62c573 wifi: rtw89: check return values in rtw89_ops_start_ap()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath10k: fix skb leak on incomplete msdu during rx pop
From: Rameshkumar Sundaram @ 2026-07-03 3:49 UTC (permalink / raw)
To: Manikanta Pubbisetty, ath10k; +Cc: linux-wireless
In-Reply-To: <20260623064355.1876743-1-manikanta.pubbisetty@oss.qualcomm.com>
On 6/23/2026 12:13 PM, Manikanta Pubbisetty wrote:
> When ath10k_htt_rx_pop_paddr32_list() or
> ath10k_htt_rx_pop_paddr64_list() encounters an incomplete frame
> (RX_ATTENTION_FLAGS_MSDU_DONE not set), it returns -EIO without
> purging the skb list built up so far, leaking any skbs already
> queued in the list.
>
> Other early-exit paths within these same functions already call
> __skb_queue_purge() before returning an error. Add it before the
> -EIO return as well to be consistent and prevent the leak.
>
> Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>
> Fixes: c545070e404b ("ath10k: implement rx reorder support")
> Fixes: 3b0b55b19d1d ("ath10k: Add support for 64 bit HTT in-order indication msg")
> Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH rtw-next 01/10] wifi: rtw89: mac: finish active TX immediately without waiting for DMAC
From: Ping-Ke Shih @ 2026-07-03 3:48 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless
Cc: gary.chang, timlee, dian_syuan0116, kevin_yang
In-Reply-To: <20260625061545.44808-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> Currently active TX only finishes after ensuring PCIE and DMAC become idle.
> However, the waiting time might be long. Since the packet is already
> transmitted over the air, update the registers to finish active TX
> immediately, regardless of the PCIE/DMAC status.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
10 patch(es) applied to rtw-next branch of rtw.git, thanks.
0819de0fd290 wifi: rtw89: mac: finish active TX immediately without waiting for DMAC
14dfbfeba17b wifi: rtw89: mac: pass chip version to firmware
e50c0fb7867e wifi: rtw89: fw: lower debug level for UDM1 debug register
c99498b4cbd7 wifi: rtw89: drop packet offload entry on H2C addition failure to avoid scan issue
b993046234fc wifi: rtw89: disable sniffer mode in RX filter when initialization for Wi-Fi 7 chips
0ec249ffc060 wifi: rtw89: pci: disable phy error flag related to refclk
c1eabaaa088d wifi: rtw89: fw: fix link ID filling for LPS MLO common info
76edcedda643 wifi: rtw89: wow: use MLD address in WoWLAN ARP replies for MLO stations
03a963f4aeda wifi: rtw89: wow: add QoS control field to WoWLAN ARP response for MLO
dbff9040587e wifi: rtw89: wow: only WiFi 6 chips initialize RF registers in WoWLAN mode
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next 01/10] wifi: rtw89: coex: force to exit Wi-Fi LPS while Bluetooth profile exist
From: Ping-Ke Shih @ 2026-07-03 3:28 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless; +Cc: ku920601
In-Reply-To: <20260624033941.45918-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Ching-Te Ku <ku920601@realtek.com>
>
> Wi-Fi can not reach LPS leave threshold while Wi-Fi only throughput
> not good & Bluetooth share bandwidth. Add logic to let force leave
> Wi-Fi LPS while Bluetooth profile exist. Update COEX version to 9.0.1.
>
> Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
10 patch(es) applied to rtw-next branch of rtw.git, thanks.
04e91bb237a4 wifi: rtw89: coex: force to exit Wi-Fi LPS while Bluetooth profile exist
ce9b6ca8f4ba wifi: rtw89: coex: offset current BT info to BT0 for dual BT configuration
6ca62c49a679 wifi: rtw89: coex: Move wifi related counters to wifi info
257cdb2c6e38 wifi: rtw89: coex: Extend bt_slot_req for dual MAC wifi
77e219a25501 wifi: rtw89: coex: Move Bluetooth related counters to BT info
195ce7889423 wifi: rtw89: coex: Refine third party module related coexistence
ebb69df34148 wifi: rtw89: coex: Add TX/RX RF parameter format version 9
600649fa9c10 wifi: rtw89: coex: Renaming drvinfo_type to drvinfo_ver
5c071a06bbba wifi: rtw89: coex: Add Wi-Fi firmware 0.35.94.1 support for RTL8922D
9a149cf572e9 wifi: rtw89: coex: Add RTL8922D chip string
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw88: Enable receiving control frames in monitor mode
From: Ping-Ke Shih @ 2026-07-03 2:55 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: Ping-Ke Shih, Georg Bißeling
In-Reply-To: <2a52d718-9e46-47f2-84a1-d8e7b1ed89a8@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> From: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
>
> By default RTL8723D, RTL8703B, RTL8812A, RTL8821A, and RTL8814A are
> configured to filter out all control frames except PS-Poll, even in
> monitor mode.
>
> Handle FIF_CONTROL in rtw_ops_configure_filter(). When it's set,
> configure REG_RXFLTMAP1 to let all control frames through. When it's
> unset, restore the original value. Because some drivers configure
> REG_RXFLTMAP1 differently, keep track of its value in a new member of
> struct rtw_hal.
>
> Signed-off-by: Bitterblue Smith (S.E.A. Datentechnik GmbH) <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
ed51a86b787f wifi: rtw88: Enable receiving control frames in monitor mode
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtl8xxxu: 8723bu: remove reference of non-existing firmware rtl8723bu_bt.bin
From: Ping-Ke Shih @ 2026-07-03 2:48 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless, Jes.Sorensen
In-Reply-To: <20260622015439.9621-1-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> A report from [1] that firmware is missing in linux-firmware repository.
> However, there is no specific firmware for RTL8723BU for Bluetooth enabled.
> Remove the unnecessary reference of firmware file.
>
> [1] https://github.com/rtlwifi-linux/rtlwifi-next/issues/20
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
1349ed8f104a wifi: rtl8xxxu: 8723bu: remove reference of non-existing firmware rtl8723bu_bt.bin
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH RESEND] wifi: ath12k: fix channel list copy on big endian
From: Baochen Qiang @ 2026-07-03 2:48 UTC (permalink / raw)
To: Alexander Wilhelm; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <akZXF0SI8jVky0Wj@FUE-ALEWI-WINX>
On 7/2/2026 8:18 PM, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 10:44:46AM +0200, Alexander Wilhelm wrote:
>> On Thu, Jul 02, 2026 at 04:27:44PM +0800, Baochen Qiang wrote:
>>>
>>>
>>> On 6/29/2026 3:46 PM, Alexander Wilhelm wrote:
>>>> The ath12k_wmi_scan_req_arg structure defines the channel list in
>>>> CPU-native order, while wmi_start_scan_cmd expects the values in
>>>> little-endian format. The simple memcpy causes the hardware scan to fail on
>>>> big-endian architectures. Set __le32* type for the tmp_ptr and swap channel
>>>> values to support both architectures correctly.
>>>>
>>>> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath12k/wmi.c | 8 +++++---
>>>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
>>>> index 65a05a9520ff..9e1d3c662852 100644
>>>> --- a/drivers/net/wireless/ath/ath12k/wmi.c
>>>> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
>>>> @@ -2571,7 +2571,8 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
>>>> struct wmi_tlv *tlv;
>>>> void *ptr;
>>>> int i, ret, len;
>>>> - u32 *tmp_ptr, extraie_len_with_pad = 0;
>>>> + __le32 *tmp_ptr;
>>>> + u32 extraie_len_with_pad = 0;
>>>> struct ath12k_wmi_hint_short_ssid_arg *s_ssid = NULL;
>>>> struct ath12k_wmi_hint_bssid_arg *hint_bssid = NULL;
>>>>
>>>> @@ -2656,9 +2657,10 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
>>>> tlv = ptr;
>>>> tlv->header = ath12k_wmi_tlv_hdr(WMI_TAG_ARRAY_UINT32, len);
>>>> ptr += TLV_HDR_SIZE;
>>>> - tmp_ptr = (u32 *)ptr;
>>>> + tmp_ptr = (__le32 *)ptr;
>>>>
>>>> - memcpy(tmp_ptr, arg->chan_list, arg->num_chan * 4);
>>>> + for (i = 0; i < arg->num_chan; i++)
>>>> + tmp_ptr[i] = cpu_to_le32(arg->chan_list[i]);
>>>>
>>>> ptr += len;
>>>>
>>>>
>>>
>>> seems hint_s_ssid and hint_bssid at the last also need the endian conversion?
>
> `hist_s_ssid` and `hint_bssid` are both structs within
> `ath12k_wmi_scan_req_arg`, and the remaining member variables are also stored in
> CPU order. Therefore, it seems wrong to me to perform byte swapping at this
> point. What I actually need to swap is the data written through `ptr`, not the
> structure members themselves. For that reason, I could also use the `__le32
> *tmp_ptr` approach. What do you think about that?
Maybe I was not clear. I intended to mean the ptr:
@@ -2728,8 +2728,8 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
ptr += TLV_HDR_SIZE;
s_ssid = ptr;
for (i = 0; i < arg->num_hint_s_ssid; ++i) {
- s_ssid->freq_flags = arg->hint_s_ssid[i].freq_flags;
- s_ssid->short_ssid = arg->hint_s_ssid[i].short_ssid;
+ s_ssid->freq_flags = cpu_to_le32(arg->hint_s_ssid[i].freq_flags);
+ s_ssid->short_ssid = cpu_to_le32(arg->hint_s_ssid[i].short_ssid);
s_ssid++;
}
ptr += len;
@@ -2743,7 +2743,7 @@ int ath12k_wmi_send_scan_start_cmd(struct ath12k *ar,
hint_bssid = ptr;
for (i = 0; i < arg->num_hint_bssid; ++i) {
hint_bssid->freq_flags =
- arg->hint_bssid[i].freq_flags;
+ cpu_to_le32(arg->hint_bssid[i].freq_flags);
ether_addr_copy(&arg->hint_bssid[i].bssid.addr[0],
&hint_bssid->bssid.addr[0]);
>
> One thing I am still unsure about is the use of `ether_addr_copy()`. Can I
> simply copy the bytes as-is here, or does the address also need to be
> byte-swapped? I could not find any place where this address is being populated,
> so I am not sure what byte order it is expected to be in.
I think you are talking about ath12k_wmi_hint_bssid_arg::bssid, right? For now ath12k does
not populate hint_bssid or hint_s_ssid members, so bssid always remain empty. But if we
are going to populate it I think the address originates from userspace and there it is
passed in byte steams, so byte-swapping not required I think.
>
>
> Best regards
> Alexander Wilhelm
^ permalink raw reply
* Re: [PATCH wireless] wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids
From: Ping-Ke Shih @ 2026-07-03 2:44 UTC (permalink / raw)
To: Runyu Xiao, Ping-Ke Shih, linux-wireless
Cc: Bitterblue Smith, linux-kernel, Runyu Xiao, Jianhao Xu, stable
In-Reply-To: <20260620025632.46206-1-runyu.xiao@seu.edu.cn>
Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> rtl92du_tx_fill_desc() uses ieee80211_get_tid() to read the QoS TID
> from the 802.11 header and then uses it as an index into
> sta_entry->tids[]. ieee80211_get_tid() returns the low 4-bit QoS TID
> value, so the result can be in the range 0..15.
>
> rtlwifi only allocates MAX_TID_COUNT entries for sta_entry->tids[], and
> MAX_TID_COUNT is 9. A QoS TID greater than 8 therefore indexes past the
> aggregation state array. Keep the default RTL_AGG_STOP state for
> out-of-range TIDs, matching rtl92cu_tx_fill_desc().
>
> This issue was detected by our static analysis tool and confirmed by
> manual audit. UBSAN validation for the same bug pattern reports an
> array-index-out-of-bounds access with index 10 for type
> 'rtl_tid_data [9]'.
>
> Fixes: 8321424134a4 ("wifi: rtlwifi: Add rtl8192du/trx.{c,h}")
> Cc: stable@vger.kernel.org
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
ed4f05d9f2f4 wifi: rtlwifi: rtl8192du: check QoS TID before indexing tids
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH wireless] wifi: rtw88: pci: fix resource leak on failed NAPI setup
From: Ping-Ke Shih @ 2026-07-03 2:41 UTC (permalink / raw)
To: Dawei Feng, pkshih
Cc: leitao, linux-wireless, linux-kernel, jianhao.xu, zilin,
Dawei Feng, stable
In-Reply-To: <20260617013502.114057-1-dawei.feng@seu.edu.cn>
Dawei Feng <dawei.feng@seu.edu.cn> wrote:
> rtw_pci_probe() allocates PCI resources through
> rtw_pci_setup_resource() before it sets up NAPI. If
> rtw_pci_napi_init() fails, the error path jumps straight to
> err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI
> resources allocated by rtw_pci_setup_resource() behind.
>
> Add a dedicated cleanup label for the NAPI setup failure path so probe
> destroys the PCI resources.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing current
> mainline kernels. The tool is still under development and is not yet
> publicly available. Manual inspection confirms that the bug is still
> present in v7.1-rc7.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have a
> suitable rtw88 PCI board to test with, no runtime testing was able to be
> performed.
>
> Fixes: d0bcb10e7b94 ("wifi: rtw88: Un-embed dummy device")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
e779df4806cd wifi: rtw88: pci: fix resource leak on failed NAPI setup
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: realtek: rtw8822c: replace msleep() with fsleep() for DPK delays
From: Ping-Ke Shih @ 2026-07-03 2:39 UTC (permalink / raw)
To: Chen Jung Ku, Ping-Ke Shih
Cc: linux-wireless, linux-kernel, Chen Jung Ku, Chen Jung Ku
In-Reply-To: <20260613170434.23645-1-ku.loong@gapp.nthu.edu.tw>
Chen Jung Ku <ku.loong@gapp.nthu.edu.tw> wrote:
> Replace msleep() with fsleep(), because msleep() may oversleep
> to as much as 20 ms when used for a 10 ms delay.
> According to the kernel documentation, fsleep() is more suitable
> and aligns better with modern kernel style.
>
> Documentation link: https://docs.kernel.org/timers/delay_sleep_functions.html
>
> Signed-off-by: Chen Jung Ku <ku.loong@gapp.nthu.edu.tw>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
000e63e67a78 wifi: rtw88: 8822c: replace msleep() with fsleep() for DPK delays
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw89: use str_enable_disable() helper
From: Ping-Ke Shih @ 2026-07-03 2:36 UTC (permalink / raw)
To: Panagiotis Petrakopoulos, Ping-Ke Shih
Cc: linux-wireless, Panagiotis Petrakopoulos
In-Reply-To: <20260612223012.504886-1-npetrakopoulos2003@gmail.com>
Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> Replace "enable"/"disable" strings in ternary expressions
> with the str_enable_disable() helper from <linux/string_choices.h>.
> This covers the rfkill state log in rtw89_core_rfkill_poll() and
> the DPK on/off log in _dpk_onoff().
>
> No functional change intended.
>
> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
2c0810030cf8 wifi: rtw89: use str_enable_disable() helper
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: fw: correct rtw89_fw_h2c_default_cmac_tbl_be()
From: Ping-Ke Shih @ 2026-07-03 2:31 UTC (permalink / raw)
To: Wentao Guan, pkshih
Cc: linux-wireless, linux-kernel, dian_syuan0116, zhanjun, niecheng1,
Wentao Guan
In-Reply-To: <20260611082021.46650-1-guanwentao@uniontech.com>
Wentao Guan <guanwentao@uniontech.com> wrote:
> BE_CCTL_INFO_W2_PRELOAD_ENABLE is for h2c->w2, not h2c->w1.
> These will cause h2c->w1 wrong overlap by w2 and w2 not initialized.
>
> Fixes: c73607b3a8ef ("wifi: rtw89: fw: add CMAC H2C command to initialize default value for RTL8922D")
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
e13cd023a4cd wifi: rtw89: fw: correct preload field of w2 in rtw89_fw_h2c_default_cmac_tbl_be()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next 1/2] wifi: rtw88: 8822c: Don't process RF path C in query_phy_status_page{0,1}
From: Ping-Ke Shih @ 2026-07-03 2:27 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
In-Reply-To: <ee30b95f-bc68-4711-9b15-cf5fd23c3c48@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> Replace <= with < in the loops in query_phy_status_page{0,1}(). They
> were processing data related to RF path C, which this chip doesn't have.
> The only bad effect seems to be that the phy_info file in debugfs was
> printing unexpected values for RF path C.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
2 patch(es) applied to rtw-next branch of rtw.git, thanks.
a4a2c1a1032f wifi: rtw88: 8822c: Don't process RF path C in query_phy_status_page{0,1}
617b1d97617b wifi: rtw88: 8822b: Don't process RF path C in query_phy_status_page1
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtlwifi: rtl8723be: Remove unnecessary irq save/restore in hw_init()
From: Ping-Ke Shih @ 2026-07-03 2:22 UTC (permalink / raw)
To: William Hansen-Baird, pkshih
Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260609095359.2964193-1-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> rtl8723be hw_init() calls local_save_flags(flags) followed by
> local_irq_enable(). Later, local_irq_restore(flags) is called.
>
> This causes warnings from Lockdep on boot and modprobe,
> as local_irq_restore(flags) should only be called while irqs are disabled.
> The warning was introduced to detect this class of bug in [1].
>
> With testing I found that all paths which call hw_init() have irqs
> already enabled for rtl8723be.
>
> Furthermore, the calls were originally added for the rtl8192ce
> in commit f78bccd79ba3 ("rtlwifi: rtl8192ce: Fix too long disable of IRQs")
> before later being added to most other rtlwifi drivers.
>
> Commit d3feae41a347 ("rtlwifi: Update power-save routines for 062814 driver")
> then replaces the call to spin_lock_irqsave() before hw_init(),
> and thus the codepath which caused irqs to be disabled in hw_init and
> prompted the original commit has been removed.
>
> The same irq save/restore pattern is also present in the hw_init() of
> rtl8192ce, rtl8723ae, rtl8188ee, rtl8192se and rtl8192cu,
> however I don't have the hardware to test them,
> so I did not include them in my changes.
>
> Tested on a Razer Blade 14 2017.
>
> Example of output from Lockdep prior to fix:
>
> raw_local_irq_restore() called with IRQs enabled
>
> ...
>
> Call Trace:
> <TASK>
> rtl8723be_hw_init+0x5992/0x7220 [rtl8723be]
> ? static_obj+0x61/0xa0
> rtl_pci_start+0x222/0x5c0 [rtl_pci]
> rtl_op_start+0x128/0x1a0 [rtlwifi]
> ? __kasan_check_read+0x11/0x20
> drv_start+0x16c/0x550 [mac80211]
>
> ...
>
> irq event stamp: 887679
> hardirqs last enabled at (887689): [<ffffffff96511170>] __up_console_sem+0x90/0xa0
> hardirqs last disabled at (887698): [<ffffffff96511155>] __up_console_sem+0x75/0xa0
> softirqs last enabled at (887670): [<ffffffff962f4675>] __irq_exit_rcu+0x175/0x2f0
> softirqs last disabled at (887649): [<ffffffff962f4675>] __irq_exit_rcu+0x175/0x2f0
> ---[ end trace 0000000000000000 ]---
>
> [1] https://lore.kernel.org/all/20210111153707.10071-1-mark.rutland@arm.com/
>
> Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
1b4cd55626b6 wifi: rtlwifi: rtl8723be: Remove unnecessary irq save/restore in hw_init()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH next] wifi: rtw89: debug: fix off by on in rtw89_ppdu_str()
From: Ping-Ke Shih @ 2026-07-03 2:19 UTC (permalink / raw)
To: Dan Carpenter, Kuan-Chung Chen
Cc: Ping-Ke Shih, linux-wireless, kernel-janitors
In-Reply-To: <aia25i0ds3B6QF6c@stanley.mountain>
Dan Carpenter <error27@gmail.com> wrote:
> This > comparison should be >= to avoid an out of bounds access.
>
> Fixes: 419ed7f4a053 ("wifi: rtw89: debug: extend bb_info with TX status and PER")
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
1 patch(es) applied to rtw-next branch of rtw.git, thanks.
1908534deb53 wifi: rtw89: debug: fix off by on in rtw89_ppdu_str()
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* Re: [PATCH rtw-next 1/2] wifi: rtw89: fw: add first set of firmware features by version for RTL8922D
From: Ping-Ke Shih @ 2026-07-03 2:16 UTC (permalink / raw)
To: Ping-Ke Shih, linux-wireless
In-Reply-To: <20260525070735.27659-2-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> The firmware features including version of command/event format are
> maintained by this table, which enables features by firmware version.
> Define the first feature set accordingly.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
2 patch(es) applied to rtw-next branch of rtw.git, thanks.
7123cb442e13 wifi: rtw89: fw: add first set of firmware features by version for RTL8922D
92827aaf07ce wifi: rtw89: fw: support scan offload v2 for WiFi 7 chips
---
https://github.com/pkshih/rtw.git
^ permalink raw reply
* [PATCH v1 1/1] wifi: mt76: mt792x: Fix memory leak in SDIO TX path
From: Eason Lai @ 2026-07-03 0:59 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Yf.Luo, kun.wu, deren.wu,
sean.wang, quan.zhou, ryder.lee, leon.yen, litien.chang, jb.tsai,
eason.lai, Eason Lai
From: Eason Lai <Eason.Lai@mediatek.com>
When tx_prepare_skb() returns an error in the SDIO TX path, the
skb is not freed, leading to a memory leak. This can occur when
zero-length frames (such as WNM NULL frames) are dropped to prevent
potential hardware TX hangs.
Fix this by properly releasing the skb with ieee80211_tx_status_ext()
when tx_prepare_skb() fails.
Fixes: b747fa343817 ("mt76: mt7915: drop zero-length packet to avoid Tx hang")
Signed-off-by: Eason Lai <Eason.Lai@mediatek.com>
---
drivers/net/wireless/mediatek/mt76/sdio.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/sdio.c b/drivers/net/wireless/mediatek/mt76/sdio.c
index 8bae77c761be..ba5f123f7e39 100644
--- a/drivers/net/wireless/mediatek/mt76/sdio.c
+++ b/drivers/net/wireless/mediatek/mt76/sdio.c
@@ -519,6 +519,10 @@ mt76s_tx_queue_skb(struct mt76_phy *phy, struct mt76_queue *q,
enum mt76_txq_id qid, struct sk_buff *skb,
struct mt76_wcid *wcid, struct ieee80211_sta *sta)
{
+ struct ieee80211_tx_status status = {
+ .sta = sta,
+ };
+
struct mt76_tx_info tx_info = {
.skb = skb,
};
@@ -531,8 +535,13 @@ mt76s_tx_queue_skb(struct mt76_phy *phy, struct mt76_queue *q,
skb->prev = skb->next = NULL;
err = dev->drv->tx_prepare_skb(dev, NULL, qid, wcid, sta, &tx_info);
- if (err < 0)
+ if (err < 0) {
+ status.skb = tx_info.skb;
+ spin_lock_bh(&dev->rx_lock);
+ ieee80211_tx_status_ext(dev->hw, &status);
+ spin_unlock_bh(&dev->rx_lock);
return err;
+ }
q->entry[q->head].skb = tx_info.skb;
q->entry[q->head].buf_sz = len;
--
2.45.2
^ permalink raw reply related
* RE: rtw89: RTL8852BE P2P-device iftype and STA+P2P interface combination
From: Ping-Ke Shih @ 2026-07-03 0:43 UTC (permalink / raw)
To: Doug Brewer; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAG0V13Si0iPLm-2KxgcEs_i+Jm4W4pM7O2KQS49dPM8HW7gK5w@mail.gmail.com>
Doug Brewer <brewer.doug@gmail.com> wrote:
> On Wed, Jul 1, 2026 at 2:40 PM Doug Brewer wrote:
> >
> > On Tue, Jun 30, 2026 at 8:51 AM Ping-Ke Shih wrote:
> > >
> > > Doug Brewer wrote:
> > > > On Mon, Jun 29, 2026 at 10:10 AM Ping-Ke Shih wrote:
> > > > >
> > > > > Doug Brewer wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm experimenting with Wi-Fi Display (Miracast sink) concurrent with an
> > > > > > STA connection on an RTL8852BE (PCIe) using the mainline rtw89 driver
> > > > > > (kernel 6.18.37).
> > > > > >
> > > > > > iw phy reports:
> > > > > > Supported interface modes:
> > > > > > * managed, AP, P2P-client, P2P-GO
> > > > > > (no P2P-device)
> > > > > > interface combinations are not supported
> > > > > >
> > > > > > In practice this blocks the standard P2P flow: there is no P2P-device
> > > > > > iftype for a dedicated discovery context, and no advertised interface
> > > > > > combination for managed + P2P-client coexistence.
> > > > > >
> > > > > > My questions:
> > > > > > 1. is P2P-device iftype support planned for rtw89 on RTL885x? Is there a
> > > > > > known technical blocker, or is it simply not yet implemented?
> > > > >
> > > > > We are planning to add P2P-device iftype. It needs to consider the cases of
> > > > > channel context, conditions of power save, and etc. It will take some time.
> > > > >
> > > > > I think it would be okay that you use STA interface to do P2P negotiation,
> > > > > and then create P2P-client or P2P-GO iftype then.
> > > > >
> > > > > > 2. would advertising a managed + P2P-client interface combination
> > > > > > (single channel) be feasible on the current rtw89?
> > > > >
> > > > > This is a SCC which is supported.
> > > > >
> > > > > > 3. is MCC (#channels > 1) on the roadmap, or considered out of scope?
> > > > >
> > > > > Current support MCC as well. However, we are cooking new firmware to support
> > > > > hw_scan with two operation channels -- which doesn't matter if you don't need
> > > > > to do scan when MCC is operating.
> > > >
> > > > Thanks for the suggestion. I tried using the STA interface for P2P
> > > > negotiation, and wanted to share what I found.
> > > >
> > > > With the STA connected (2.4GHz ch11) and an active p2p_connect, a
> > > > wpa_supplicant -dd trace shows GO negotiation getting fairly far:
> > > >
> > > > Peer's GO-NEG Request is received
> > > > send the GO-NEG Response on ch11, peer ACKs it (TX ack=1)
> > > > State goes GO_NEG -> CONNECT
> > > > then time out waiting for the GO-NEG Confirm, status=-1
> > > >
> > > > I select ch11 as the P2P operating channel (same as STA, SCC), while
> > > > the peer's operating preference is 5GHz ch149. It looks like after we TX
> > > > the Response, the radio doesn't stay on ch11 to listen for the Confirm,
> > > > so the frame is missed -- presumably because the single radio is serving
> > > > the STA connection.
> > >
> > > So, peer doesn't stay ch11 to complete he negotiation, right?
> > >
> > > What is the peer device you are using? Can you setup another RTL8852BE?
> > > I suggest running simple scenario first to dig cause.
> > >
> > > 1. two peers make P2P group without any STA connection
> > > 2. RTL8852BE with a STA connection, and peer without connection.
> > >
> > > >
> > > > Aalso tested with the STA on 5GHz (ch149); the result is the same
> > > > GO-NEG Confirm timeout.
> > > >
> > > > Is this the channel-context issue that P2P-device iftype will address?
> > > > And with the current driver, is there any way to keep the P2P listen
> > > > context on the operating channel during GO negotiation while STA is up?
> > >
> > > Before P2P negotiation completion, there is only one channel context.
> > > The second interface (GC or GO) is created when the P2P role is decided
> > > by P2P negotiation.
> > >
> > > You need to check supplicant log about channels on both peers. I think
> > > remain-on-channel is the method supplicant switch channel to send
> > > negotiation frames and to stay on listen channel.
> > >
> > > >
> > > > (FWIW, passing an explicit freq= to p2p_connect is rejected with FAIL,
> > > > whether or not it matches the STA channel.)
> > >
> > > Not sure why. In our side, it seems work.
> > >
> > >
> > > I'd share a pair of wpa_supplicant .conf and wpa_cli commands we are testing
> > > for reference.
> >
> > Great progress using your test conf and a second RTL8852BE. Results:
> >
> > Two RTL8852BE peers, no STA — P2P connects fine (GO/client, group formed,
> > 4-way HS completed).
> >
> > One RTL8852BE with STA on 5GHz ch149, the other RTL8852BE with no STA,
> > also succeeds. The GO comes up on ch153 while the STA stays on ch149 (so MCC),
> > group formed, client connected. Both sides confirmed via iw dev
> > (GO on ch153 + STA on ch149; peer client on ch153).
> >
> > So STA + P2P coexistence, including MCC, works fine between two 8852BE peers.
> >
> > p2p_no_group_iface=1 in your conf may have contributed, P2P runs on the main
> > interface instead of a separate group interface.
> >
> > Thank you very much for the test conf and guidance.
>
> One more update. Two RTL8852BE peers (STA + P2P) work reliably, as
> reported.
>
> However, with a Samsung phone as the peer, GO negotiation is
> inconsistent — using your conf (including p2p_no_group_iface=1), the same
> setup sometimes completes and sometimes fails with GO-NEG Confirm timeout
> (status=-1).
>
> Do you have any suggestion for this case with a real phone peer?
I'd suggest the simplest use case which your Samsung phone doesn't connect to
an AP, and remove all STA networks from the phone. That means the phone only
has one interface working on P2P.
If you need to dig the problems related to P2P channels, I suggest you can
setup RTL8852BE sniffer to capture packets on two channels simultaneously.
One method is to install two RTL8852BE in a computer, and use single one
wireshark to capture two interfaces (setup the two channels manually).
The other is to setup two computers to capture each of two channels,
and then merge the sniffer files (note that you must synchronize the
host time to merge the files properly).
Ping-Ke
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix survey indexing across bands
From: Nicolas Escande @ 2026-07-02 21:14 UTC (permalink / raw)
To: Matthew Leach, Jeff Johnson, Vasanthakumar Thiagarajan,
Baochen Qiang, Ramya Gnanasekar, Karthikeyan Periyasamy
Cc: Pradeep Kumar Chitrapu, P Praneesh, Sriram R, linux-wireless,
ath12k, linux-kernel, kernel, Rameshkumar Sundaram,
Rameshkumar Sundaram, Jeff Johnson
In-Reply-To: <20260702-ath12-survey-band-fix-v2-1-75b5bdf72a08@collabora.com>
On Thu Jul 2, 2026 at 12:50 PM CEST, Matthew Leach wrote:
> When running 'iw dev wlan0 survey dump' the values for the channel busy
> time have the same sequence across bands. This is caused by indexing
> into the ath12k survey array using a band-local index rather than the
> global index passed by mac80211. This results in surveys for 5 GHz and 6
> GHz channels returning values from 2.4 GHz slots, making the survey
> unusable on those bands. Further, there are redundant survey slots for
> multi-radio/single-phy instances.
>
> Fix by moving the survey data into ath12k_hw so multiple radios under a
> single wiphy share one table, and index into it using the global
> mac80211 index. A new spinlock in ath12k_hw serialises access to the
> survey array, which is now shared across all radios under a single hw.
>
> Band busy-times Before this fix:
>
> 2.4 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
> 5 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
> 6 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
>
> After this fix, times are independent:
>
> 2.4 GHz: 23, 5, 5, 12, 2, 12, 26, 5, 3, 1, 27
> 5 GHz: 30, 40, 29, 27, 118, 118, 112, 120, 11, 11, 11
> 6 GHz: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
>
> Tested-on: wcn7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
>
Hello,
I see that this is supposed to work on single phy device, but could someone
do a proper test to ensure that it will work on QCN9274 split phy ?
I know this is a big ask, and usually I would do it, but I do not have a setup
with a new enough kernel running to test this right now.
Thanks
> Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy")
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
^ permalink raw reply
* Re: [ath-current] wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin
From: Jeff Johnson @ 2026-07-02 21:06 UTC (permalink / raw)
To: ath11k, linux-wireless, Gaole Zhang; +Cc: miaoqing.pan, hangtian.zhu
In-Reply-To: <20260609090609.4041009-1-gaole.zhang@oss.qualcomm.com>
On Tue, 09 Jun 2026 17:06:09 +0800, Gaole Zhang wrote:
> In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set
> unconditionally even when ath11k_core_qmi_firmware_ready() fails.
> This leaves the driver in an inconsistent state where
> initialization is considered complete although the firmware ready
> handling did not finish successfully. During the subsequent SSR,
> the driver enters the restart path based on this incorrect state
> and dereferences uninitialized srng members, resulting in a NULL
> pointer dereference.
>
> [...]
Applied, thanks!
[1/1] wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin
commit: e8d85672dd7e2523f774caafba8f858384e18df7
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath6kl: fix use-after-free in aggr_reset_state()
From: Jeff Johnson @ 2026-07-02 21:06 UTC (permalink / raw)
To: linux-wireless, Daniel Hodges
Cc: tglx, mingo, joe, vthiagar, rmani, jouni, kvalo, linux-kernel,
stable
In-Reply-To: <20260206185207.30098-1-git@danielhodges.dev>
On Fri, 06 Feb 2026 13:52:07 -0500, Daniel Hodges wrote:
> The aggr_reset_state() function uses timer_delete() (non-synchronous)
> for the aggregation timer before proceeding to delete TID state and
> before the structure is freed by callers like aggr_module_destroy().
>
> If the timer callback (aggr_timeout) is executing when aggr_reset_state()
> is called, the callback will continue to access aggr_conn fields like
> rx_tid[] and stat[] which may be freed immediately after by
> kfree(aggr_info->aggr_conn) in aggr_module_destroy().
>
> [...]
Applied, thanks!
[1/1] wifi: ath6kl: fix use-after-free in aggr_reset_state()
commit: ba7debb4dd6427386862220e8335a53a4bfc235d
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request
From: Jeff Johnson @ 2026-07-02 21:06 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo, xiaoblac
Cc: Oleksij Rempel, linux-wireless, linux-kernel, syzkaller-bugs,
syzbot+50122cbc2874b1eb25b0
In-Reply-To: <20260605153210.20471-1-1020691186@qq.com>
On Fri, 05 Jun 2026 08:32:10 -0700, xiaoblac wrote:
> ath9k_hif_request_firmware() re-arms an asynchronous firmware load via
> request_firmware_nowait(), passing hif_dev as the completion context, and
> then still dereferences hif_dev:
>
> dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
> hif_dev->fw_name);
>
> [...]
Applied, thanks!
[1/1] wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request
commit: dad9f96945d77ecd4708f730c06ef54dcd8cc057
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Mathieu Poirier @ 2026-07-02 19:14 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, 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, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jenswi, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260702115835.167602-1-sumit.garg@kernel.org>
Hey Sumit - nice hearing from you...
Is there some kind of overarching design harminisation between what
you are proposing here and what Arnaud posted back in April [1] ?
[1]. https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmware.org/thread/VMKTRATYUFWL2TP7NHN5KJ37MSVZZMPK/
On Thu, 2 Jul 2026 at 05:59, Sumit Garg <sumit.garg@kernel.org> 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 and lemans
> EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with
> 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 generic PAS service.
> - Patch #2: migrates SCM backend to generic PAS service.
> - Patch #3: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #4-#12: migrates all client drivers to generic PAS service.
> - Patch #13: drops legacy PAS SCM exported APIs.
>
> The patch-set is based on v7.2-rc1 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-v9
>
> ---
> Changes in v9:
> - Rebased to 7.2-rc1.
> - Enable SCM backend similar to TEE if ARCH_QCOM is set.
> - Address misc. comments from Konrad.
> - Add checks for corner cases (although not reachable as per OP-TEE ABI)
> reported by Shashiko on patch #3.
> - Picked up review tags from Konrad.
>
> Changes in v8:
> - Rebased on mainline tip (no functional changes).
> - Now Lemans EVK is also tested to support OP-TEE PAS here:
> https://github.com/OP-TEE/optee_os/pull/7845
> - Drop Kodiak DT patch as it is carried independently by Mukesh here:
> https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualcomm.com/
> - Regarding Sashiko comments, I have already replied in v6 the ones that
> don't apply but in v7 I got the same comments again. Specific context
> reasoning which Shashiko ignores:
> - ABI contract between Linux and TZ
> - No support for multiple concurrent backends
> - The TZ backend doesn’t detach during the entire boot cycle
>
> Changes in v7:
> - Rebased to qcom tree (for-next branch) tip.
> - Merged patch #5 and #7 due to build dependency.
> - Disabled modem for kodiak EL2 as it isn't tested yet.
> - Fix an issue found out by sashiko-bot for patch #4.
>
> Changes in v6:
> - Rebased to v7.1-rc4 tag.
> - Patch #14: fixed ret error print.
> - Add Kconfig descriptions for PAS symbols such that they are visible
> in menuconfig to update.
>
> 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.
>
> Sumit Garg (14):
> 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
> 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 +
> drivers/firmware/qcom/Kconfig | 22 +-
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 299 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++
> 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 | 27 +-
> .../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 | 10 +-
> 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 +-
> 26 files changed, 1095 insertions(+), 321 deletions(-)
> 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.53.0
>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix survey indexing across bands
From: Rameshkumar Sundaram @ 2026-07-02 18:06 UTC (permalink / raw)
To: Matthew Leach, Jeff Johnson, Vasanthakumar Thiagarajan,
Baochen Qiang
Cc: Kalle Valo, Pradeep Kumar Chitrapu, linux-wireless, ath12k,
linux-kernel, kernel, Rameshkumar Sundaram, Jeff Johnson
In-Reply-To: <20260702-ath12-survey-band-fix-v2-1-75b5bdf72a08@collabora.com>
On 7/2/2026 4:20 PM, Matthew Leach wrote:
> When running 'iw dev wlan0 survey dump' the values for the channel busy
> time have the same sequence across bands. This is caused by indexing
> into the ath12k survey array using a band-local index rather than the
> global index passed by mac80211. This results in surveys for 5 GHz and 6
> GHz channels returning values from 2.4 GHz slots, making the survey
> unusable on those bands. Further, there are redundant survey slots for
> multi-radio/single-phy instances.
>
> Fix by moving the survey data into ath12k_hw so multiple radios under a
> single wiphy share one table, and index into it using the global
> mac80211 index. A new spinlock in ath12k_hw serialises access to the
> survey array, which is now shared across all radios under a single hw.
>
> Band busy-times Before this fix:
>
> 2.4 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
> 5 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
> 6 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
>
> After this fix, times are independent:
>
> 2.4 GHz: 23, 5, 5, 12, 2, 12, 26, 5, 3, 1, 27
> 5 GHz: 30, 40, 29, 27, 118, 118, 112, 120, 11, 11, 11
> 6 GHz: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
>
> Tested-on: wcn7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
>
> Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy")
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
> ---
> Changes in v2:
> - Move survey[] from ath12k to ath12k_hw so multi-radio single-wiphy
> setups share one global table (suggested by Rameshkumar Sundaram).
> - Drop the ar->mac.sbands[] filter in freq_to_idx() so the WMI event
> handlers use the same global index
> - Add ah->survey_lock to serialise access to the shared survey table
> - Update Fixes: tag to the correct commit
> - Link to v1: https://patch.msgid.link/20260617-ath12-survey-band-fix-v1-1-e7d9555bb478@collabora.com
>
> To: Jeff Johnson <jjohnson@kernel.org>
> To: Sriram R <quic_srirrama@quicinc.com>
> To: Kalle Valo <kvalo@kernel.org>
> To: Rameshkumar Sundaram <quic_ramess@quicinc.com>
> Cc: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: ath12k@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/wireless/ath/ath12k/core.h | 6 ++++-
> drivers/net/wireless/ath/ath12k/mac.c | 33 ++++++++++++++-------------
> drivers/net/wireless/ath/ath12k/wmi.c | 41 ++++++++++++++++++----------------
> 3 files changed, 45 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 8be435535a4e..6ce2f7b3fa50 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -712,7 +712,6 @@ struct ath12k {
> * avoid reporting garbage data.
> */
> bool ch_info_can_report_survey;
> - struct survey_info survey[ATH12K_NUM_CHANS];
> struct completion bss_survey_done;
>
> struct work_struct regd_update_work;
> @@ -774,6 +773,11 @@ struct ath12k_hw {
> */
> struct mutex hw_mutex;
> enum ath12k_hw_state state;
> +
> + /* protects survey[] shared across radios of this hw. */
> + spinlock_t survey_lock;
> + struct survey_info survey[ATH12K_NUM_CHANS];
> +
> bool regd_updated;
> bool use_6ghz_regd;
>
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index 2cff9485c95a..daf9bc8722df 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -13348,52 +13348,54 @@ ath12k_mac_update_bss_chan_survey(struct ath12k *ar,
> int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
> struct survey_info *survey)
> {
> + struct ath12k_hw *ah = hw->priv;
> struct ath12k *ar;
> struct ieee80211_supported_band *sband;
> - struct survey_info *ar_survey;
> + struct survey_info *ah_survey;
> + int sband_idx = idx;
>
> lockdep_assert_wiphy(hw->wiphy);
>
> - if (idx >= ATH12K_NUM_CHANS)
> + if (sband_idx >= ATH12K_NUM_CHANS)
> return -ENOENT;
>
> sband = hw->wiphy->bands[NL80211_BAND_2GHZ];
> - if (sband && idx >= sband->n_channels) {
> - idx -= sband->n_channels;
> + if (sband && sband_idx >= sband->n_channels) {
> + sband_idx -= sband->n_channels;
> sband = NULL;
> }
>
> if (!sband)
> sband = hw->wiphy->bands[NL80211_BAND_5GHZ];
> - if (sband && idx >= sband->n_channels) {
> - idx -= sband->n_channels;
> + if (sband && sband_idx >= sband->n_channels) {
> + sband_idx -= sband->n_channels;
> sband = NULL;
> }
>
> if (!sband)
> sband = hw->wiphy->bands[NL80211_BAND_6GHZ];
>
> - if (!sband || idx >= sband->n_channels)
> + if (!sband || sband_idx >= sband->n_channels)
> return -ENOENT;
>
> - ar = ath12k_mac_get_ar_by_chan(hw, &sband->channels[idx]);
> + ar = ath12k_mac_get_ar_by_chan(hw, &sband->channels[sband_idx]);
> if (!ar) {
> - if (sband->channels[idx].flags & IEEE80211_CHAN_DISABLED) {
> + if (sband->channels[sband_idx].flags & IEEE80211_CHAN_DISABLED) {
> memset(survey, 0, sizeof(*survey));
> return 0;
> }
> return -ENOENT;
> }
>
> - ar_survey = &ar->survey[idx];
> + ah_survey = &ah->survey[idx];
>
> - ath12k_mac_update_bss_chan_survey(ar, &sband->channels[idx]);
> + ath12k_mac_update_bss_chan_survey(ar, &sband->channels[sband_idx]);
>
> - spin_lock_bh(&ar->data_lock);
> - memcpy(survey, ar_survey, sizeof(*survey));
> - spin_unlock_bh(&ar->data_lock);
> + scoped_guard(spinlock_bh, &ah->survey_lock) {
> + memcpy(survey, ah_survey, sizeof(*survey));
> + }
>
> - survey->channel = &sband->channels[idx];
> + survey->channel = &sband->channels[sband_idx];
>
> if (ar->rx_channel == survey->channel)
> survey->filled |= SURVEY_INFO_IN_USE;
> @@ -15055,6 +15057,7 @@ static struct ath12k_hw *ath12k_mac_hw_allocate(struct ath12k_hw_group *ag,
>
> mutex_init(&ah->hw_mutex);
>
> + spin_lock_init(&ah->survey_lock);
> spin_lock_init(&ah->dp_hw.peer_lock);
> INIT_LIST_HEAD(&ah->dp_hw.dp_peers_list);
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index b5e904a55aea..aa70d2a61d38 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -6617,16 +6617,12 @@ static int ath12k_pull_roam_ev(struct ath12k_base *ab, struct sk_buff *skb,
> return 0;
> }
>
> -static int freq_to_idx(struct ath12k *ar, int freq)
> +static int freq_to_idx(struct ieee80211_hw *hw, int freq)
> {
> struct ieee80211_supported_band *sband;
> - struct ieee80211_hw *hw = ath12k_ar_to_hw(ar);
> int band, ch, idx = 0;
>
> for (band = NL80211_BAND_2GHZ; band < NUM_NL80211_BANDS; band++) {
> - if (!ar->mac.sbands[band].channels)
> - continue;
> -
> sband = hw->wiphy->bands[band];
> if (!sband)
> continue;
> @@ -7507,6 +7503,7 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> {
> struct wmi_chan_info_event ch_info_ev = {};
> struct ath12k *ar;
> + struct ath12k_hw *ah;
> struct survey_info *survey;
> int idx;
> /* HW channel counters frequency value in hertz */
> @@ -7538,6 +7535,7 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> return;
> }
> spin_lock_bh(&ar->data_lock);
> + ah = ath12k_ar_to_ah(ar);
>
> switch (ar->scan.state) {
> case ATH12K_SCAN_IDLE:
> @@ -7549,8 +7547,8 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> break;
> }
>
> - idx = freq_to_idx(ar, le32_to_cpu(ch_info_ev.freq));
> - if (idx >= ARRAY_SIZE(ar->survey)) {
> + idx = freq_to_idx(ath12k_ar_to_hw(ar), le32_to_cpu(ch_info_ev.freq));
> + if (idx >= ARRAY_SIZE(ah->survey)) {
> ath12k_warn(ab, "chan info: invalid frequency %d (idx %d out of bounds)\n",
> ch_info_ev.freq, idx);
> goto exit;
> @@ -7563,14 +7561,16 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> cc_freq_hz = (le32_to_cpu(ch_info_ev.mac_clk_mhz) * 1000);
>
> if (ch_info_ev.cmd_flags == WMI_CHAN_INFO_START_RESP) {
> - survey = &ar->survey[idx];
> - memset(survey, 0, sizeof(*survey));
> - survey->noise = le32_to_cpu(ch_info_ev.noise_floor);
> - survey->filled = SURVEY_INFO_NOISE_DBM | SURVEY_INFO_TIME |
> + scoped_guard(spinlock_bh, &ah->survey_lock) {
> + survey = &ah->survey[idx];
> + memset(survey, 0, sizeof(*survey));
> + survey->noise = le32_to_cpu(ch_info_ev.noise_floor);
> + survey->filled = SURVEY_INFO_NOISE_DBM | SURVEY_INFO_TIME |
> SURVEY_INFO_TIME_BUSY;
> - survey->time = div_u64(le32_to_cpu(ch_info_ev.cycle_count), cc_freq_hz);
> - survey->time_busy = div_u64(le32_to_cpu(ch_info_ev.rx_clear_count),
> - cc_freq_hz);
> + survey->time = div_u64(le32_to_cpu(ch_info_ev.cycle_count), cc_freq_hz);
> + survey->time_busy = div_u64(le32_to_cpu(ch_info_ev.rx_clear_count),
> + cc_freq_hz);
> + }
> }
> exit:
> spin_unlock_bh(&ar->data_lock);
> @@ -7583,6 +7583,7 @@ ath12k_pdev_bss_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> struct wmi_pdev_bss_chan_info_event bss_ch_info_ev = {};
> struct survey_info *survey;
> struct ath12k *ar;
> + struct ath12k_hw *ah;
> u32 cc_freq_hz = ab->cc_freq_hz;
> u64 busy, total, tx, rx, rx_bss;
> int idx;
> @@ -7623,15 +7624,18 @@ ath12k_pdev_bss_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> return;
> }
>
> - 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)) {
> + ah = ath12k_ar_to_ah(ar);
> +
> + guard(spinlock_bh)(&ah->survey_lock);
> +
> + idx = freq_to_idx(ath12k_ar_to_hw(ar), le32_to_cpu(bss_ch_info_ev.freq));
> + if (idx >= ARRAY_SIZE(ah->survey)) {
> ath12k_warn(ab, "bss chan info: invalid frequency %d (idx %d out of bounds)\n",
> bss_ch_info_ev.freq, idx);
> goto exit;
> }
>
the scope of survey_lock should start here and ..
> - survey = &ar->survey[idx];
> + survey = &ah->survey[idx];
>
> survey->noise = le32_to_cpu(bss_ch_info_ev.noise_floor);
> survey->time = div_u64(total, cc_freq_hz);
> @@ -7644,7 +7648,6 @@ ath12k_pdev_bss_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> SURVEY_INFO_TIME_RX |
> SURVEY_INFO_TIME_TX);
> exit:
> - spin_unlock_bh(&ar->data_lock);
end here, may be a scoped guard here as well ?
> complete(&ar->bss_survey_done);
>
> rcu_read_unlock();
>
> ---
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> change-id: 20260617-ath12-survey-band-fix-4b5e78579379
>
> Best regards,
> --
> Matt
>
Rest of the changes looks fine to me.
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations
From: Jose Ignacio Tornos Martinez @ 2026-07-02 13:42 UTC (permalink / raw)
To: johannes; +Cc: jtornosm, linux-wireless, lorenzo, nbd, ryder.lee, shayne.chen
In-Reply-To: <0723f2f3ddb22ce4b9a1c2d075126c8987031a6a.camel@sipsolutions.net>
Hi Johannes,
You're absolutely right - I had the wrong commit title. It should be
"cfg80211: disallow beacon_int_min_gcd with IBSS".
I've already sent v2 with the correction.
Thanks for the quick review
Best regards
Jose Ignacio
^ 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