* Re: [PATCH ath-next v3] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Baochen Qiang @ 2026-06-29 2:24 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260626084327.2022076-1-aaradhana.sahu@oss.qualcomm.com>
On 6/26/2026 4:43 PM, Aaradhana Sahu wrote:
> On AHB platforms, firmware operates in two modes: fixed-memory mode where
> firmware uses hardcoded addresses for memory regions such as BDF and does
> not request HOST_DDR memory from the host, and dynamic-memory mode where
> firmware expects the host to provide memory addresses including HOST_DDR
> after the Q6 read-only region and relies on host allocation for all memory
> types.
>
> Introduce QMI capability negotiation to support both modes. Add a new QMI
> PHY capability flag dynamic_ddr_support which is advertised by firmware to
> indicate it supports dynamic memory mode. When the host detects this
> capability, set the dynamic_mem_support flag in the host capability message
> to signal the host is ready to provide dynamic memory allocation. This
> triggers firmware to send the HOST_DDR memory request and use the
> host-provided address.
>
> For backward compatibility, if firmware doesn't advertise
> dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
> where firmware uses predefined addresses.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: change MAC buffer ring size to 4096
From: Baochen Qiang @ 2026-06-29 2:16 UTC (permalink / raw)
To: Yingying Tang, ath12k; +Cc: linux-wireless, yintang
In-Reply-To: <20260610031358.2043716-1-yingying.tang@oss.qualcomm.com>
On 6/10/2026 11:13 AM, Yingying Tang wrote:
> For WCN7850, MAC buffer ring size is updated to 2048 in
> 955df16f2a4c3 ("wifi: ath12k: change MAC buffer ring size to 2048")
> to increase peak throughput.
>
> But during the RX process, a phenomenon can still be observed where
> the throughput drops by about 30% from its peak value and then recovers,
> and this behavior repeats during RX.
>
> After increasing MAC buffer ring size to 4096, the data rate drop has
> gone.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/3] wifi: ath12k: Fix memory allocation and improve reserved memory handling
From: Baochen Qiang @ 2026-06-29 2:15 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260611033314.2330-1-aaradhana.sahu@oss.qualcomm.com>
On 6/11/2026 11:33 AM, Aaradhana Sahu wrote:
> The current implementation relies on index-based device tree reserved
> memory lookup. Different platform variants define reserved memory
> regions in different orders and combinations, making the index-based
> lookup fragile across platforms.
>
> Currently, the driver allocates the HOST_DDR_REGION_TYPE
> starting from the base of the Q6 region, which overlaps the Q6 read-only
> firmware section. This causes firmware assertions during QMI memory
> allocation, as the firmware expects writable regions to be placed after the
> read-only section.
>
> Address these issues by:
> - switching to name-based reserved memory lookup to remove dependency on
> device tree node ordering,
> - refactoring QMI memory assignment logic to reduce code duplication and
> improve maintainability,
> - placing HOST_DDR and BDF regions after the Q6 read-only firmware section
> using the bdf_addr_offset parameter.
>
> This series ensure correct reserved memory handling across different
> platform variants, prevent overlapping memory allocations, and maintain
> backward compatibility by reusing existing reserved memory region names
> defined in device tree bindings.
>
> Overview:
> - Patch [1/3] switches to name-based reserved memory lookup for platform
> compatibility.
> - Patch [2/3] refactors QMI memory assignment to eliminate code
> duplication.
> - Patch [3/3] fixes memory allocation to place HOST_DDR and BDF regions
> after Q6 read-only section.
>
> Aaradhana Sahu (3):
> wifi: ath12k: switch to name-based reserved memory lookup
> wifi: ath12k: refactor QMI memory assignment
> wifi: ath12k: allocate HOST_DDR and BDF regions after Q6 RO region
>
> drivers/net/wireless/ath/ath12k/ahb.c | 18 +--
> drivers/net/wireless/ath/ath12k/core.c | 25 ----
> drivers/net/wireless/ath/ath12k/core.h | 2 -
> drivers/net/wireless/ath/ath12k/qmi.c | 168 ++++++++++---------------
> 4 files changed, 78 insertions(+), 135 deletions(-)
>
>
> base-commit: 83f028be15fe071efbee8e27837538d6cca77e87
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] Revert "wifi: ath12k: add panic handler"
From: Baochen Qiang @ 2026-06-29 2:10 UTC (permalink / raw)
To: Yingying Tang, ath12k; +Cc: linux-wireless, yintang
In-Reply-To: <20260612032332.2278338-1-yingying.tang@oss.qualcomm.com>
On 6/12/2026 11:23 AM, Yingying Tang wrote:
> This reverts commit 809055628bce824b7fe18331abb65e44d02b0ecf.
>
> Call trace:
> rcu_note_context_switch+0x4c4/0x508 (P)
> __schedule+0xbc/0x1204
> schedule+0x34/0x110
> schedule_timeout+0x84/0x11c
> __mhi_device_get_sync+0x164/0x228 [mhi]
> mhi_device_get_sync+0x1c/0x3c [mhi]
> ath12k_wifi7_pci_bus_wake_up+0x20/0x2c [ath12k_wifi7]
> ath12k_pci_read32+0x58/0x350 [ath12k]
> ath12k_pci_clear_dbg_registers+0x28/0xb8 [ath12k]
> ath12k_pci_panic_handler+0x20/0x44 [ath12k] ath12k_core_panic_handler+0x28/0x3c [ath12k]
> notifier_call_chain+0x78/0x1c0
> atomic_notifier_call_chain+0x3c/0x5c
>
> ath12k_core_panic_handler() is invoked via atomic_notifier_call_chain(),
> which runs inside an RCU read-side critical section. The current code calls
> ath12k_pci_sw_reset() synchronously from this context, which eventually
> reaches mhi_device_get_sync() and schedule_timeout(), triggering a voluntary
> context switch within RCU.
>
> Revert change "wifi: ath12k: add panic handler" to avoid this issue.
>
> Tested-on: WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
incorrect Tested-on: tag format
>
Fixes: ?
> Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/core.c | 33 +-------------------------
> drivers/net/wireless/ath/ath12k/core.h | 3 ---
> drivers/net/wireless/ath/ath12k/hif.h | 9 -------
> drivers/net/wireless/ath/ath12k/pci.c | 8 -------
> 4 files changed, 1 insertion(+), 52 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index 1a9866061f82..6705a8a73de1 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -1793,29 +1793,6 @@ int ath12k_core_pre_init(struct ath12k_base *ab)
> return 0;
> }
>
> -static int ath12k_core_panic_handler(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct ath12k_base *ab = container_of(nb, struct ath12k_base,
> - panic_nb);
> -
> - return ath12k_hif_panic_handler(ab);
> -}
> -
> -static int ath12k_core_panic_notifier_register(struct ath12k_base *ab)
> -{
> - ab->panic_nb.notifier_call = ath12k_core_panic_handler;
> -
> - return atomic_notifier_chain_register(&panic_notifier_list,
> - &ab->panic_nb);
> -}
> -
> -static void ath12k_core_panic_notifier_unregister(struct ath12k_base *ab)
> -{
> - atomic_notifier_chain_unregister(&panic_notifier_list,
> - &ab->panic_nb);
> -}
> -
> static inline
> bool ath12k_core_hw_group_create_ready(struct ath12k_hw_group *ag)
> {
> @@ -2212,18 +2189,13 @@ int ath12k_core_init(struct ath12k_base *ab)
> struct ath12k_hw_group *ag;
> int ret;
>
> - ret = ath12k_core_panic_notifier_register(ab);
> - if (ret)
> - ath12k_warn(ab, "failed to register panic handler: %d\n", ret);
> -
> mutex_lock(&ath12k_hw_group_mutex);
>
> ag = ath12k_core_hw_group_assign(ab);
> if (!ag) {
> mutex_unlock(&ath12k_hw_group_mutex);
> ath12k_warn(ab, "unable to get hw group\n");
> - ret = -ENODEV;
> - goto err_unregister_notifier;
> + return -ENODEV;
> }
>
> mutex_unlock(&ath12k_hw_group_mutex);
> @@ -2248,8 +2220,6 @@ int ath12k_core_init(struct ath12k_base *ab)
>
> err_unassign_hw_group:
> ath12k_core_hw_group_unassign(ab);
> -err_unregister_notifier:
> - ath12k_core_panic_notifier_unregister(ab);
>
> return ret;
> }
> @@ -2258,7 +2228,6 @@ void ath12k_core_deinit(struct ath12k_base *ab)
> {
> ath12k_core_hw_group_destroy(ab->ag);
> ath12k_core_hw_group_unassign(ab);
> - ath12k_core_panic_notifier_unregister(ab);
> }
>
> void ath12k_core_free(struct ath12k_base *ab)
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 4edc8f4e0cb5..a81cb3032145 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -15,7 +15,6 @@
> #include <linux/ctype.h>
> #include <linux/firmware.h>
> #include <linux/of_reserved_mem.h>
> -#include <linux/panic_notifier.h>
> #include <linux/average.h>
> #include <linux/of.h>
> #include <linux/rhashtable.h>
> @@ -1121,8 +1120,6 @@ struct ath12k_base {
>
> #endif /* CONFIG_ACPI */
>
> - struct notifier_block panic_nb;
> -
> struct ath12k_hw_group *ag;
> struct ath12k_wsi_info wsi_info;
> enum ath12k_firmware_mode fw_mode;
> diff --git a/drivers/net/wireless/ath/ath12k/hif.h b/drivers/net/wireless/ath/ath12k/hif.h
> index e8840fab6061..42bb00c13ef3 100644
> --- a/drivers/net/wireless/ath/ath12k/hif.h
> +++ b/drivers/net/wireless/ath/ath12k/hif.h
> @@ -30,7 +30,6 @@ struct ath12k_hif_ops {
> void (*ce_irq_enable)(struct ath12k_base *ab);
> void (*ce_irq_disable)(struct ath12k_base *ab);
> void (*get_ce_msi_idx)(struct ath12k_base *ab, u32 ce_id, u32 *msi_idx);
> - int (*panic_handler)(struct ath12k_base *ab);
> void (*coredump_download)(struct ath12k_base *ab);
> };
>
> @@ -149,14 +148,6 @@ static inline void ath12k_hif_power_down(struct ath12k_base *ab, bool is_suspend
> ab->hif.ops->power_down(ab, is_suspend);
> }
>
> -static inline int ath12k_hif_panic_handler(struct ath12k_base *ab)
> -{
> - if (!ab->hif.ops->panic_handler)
> - return NOTIFY_DONE;
> -
> - return ab->hif.ops->panic_handler(ab);
> -}
> -
> static inline void ath12k_hif_coredump_download(struct ath12k_base *ab)
> {
> if (ab->hif.ops->coredump_download)
> diff --git a/drivers/net/wireless/ath/ath12k/pci.c b/drivers/net/wireless/ath/ath12k/pci.c
> index 375277ca2b89..65a780e74d01 100644
> --- a/drivers/net/wireless/ath/ath12k/pci.c
> +++ b/drivers/net/wireless/ath/ath12k/pci.c
> @@ -1469,13 +1469,6 @@ void ath12k_pci_power_down(struct ath12k_base *ab, bool is_suspend)
> ath12k_pci_sw_reset(ab_pci->ab, false);
> }
>
> -static int ath12k_pci_panic_handler(struct ath12k_base *ab)
> -{
> - ath12k_pci_sw_reset(ab, false);
> -
> - return NOTIFY_OK;
> -}
> -
> static const struct ath12k_hif_ops ath12k_pci_hif_ops = {
> .start = ath12k_pci_start,
> .stop = ath12k_pci_stop,
> @@ -1493,7 +1486,6 @@ static const struct ath12k_hif_ops ath12k_pci_hif_ops = {
> .ce_irq_enable = ath12k_pci_hif_ce_irq_enable,
> .ce_irq_disable = ath12k_pci_hif_ce_irq_disable,
> .get_ce_msi_idx = ath12k_pci_get_ce_msi_idx,
> - .panic_handler = ath12k_pci_panic_handler,
> #ifdef CONFIG_ATH12K_COREDUMP
> .coredump_download = ath12k_pci_coredump_download,
> #endif
^ permalink raw reply
* RE: rtw89: RTL8852BE P2P-device iftype and STA+P2P interface combination
From: Ping-Ke Shih @ 2026-06-29 2:10 UTC (permalink / raw)
To: Doug Brewer, linux-wireless@vger.kernel.org
In-Reply-To: <CAG0V13TRHzXtoMY=XZMOd=WjzS58Cu=aePFCz8mY6UoGYm5dXw@mail.gmail.com>
Doug Brewer <brewer.doug@gmail.com> 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.
Ping-Ke
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: correct monitor destination ring size
From: Baochen Qiang @ 2026-06-29 2:07 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260616062342.4079796-1-aaradhana.sahu@oss.qualcomm.com>
On 6/16/2026 2:23 PM, Aaradhana Sahu wrote:
> The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
> which is a typo. The intended value is 8192, consistent with all other ring
> sizes in the table being powers of two.
>
> Correct the monitor destination ring size to 8192.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Fixes: defae535dd63 ("wifi: ath12k: Add a table of parameters entries impacting memory consumption")
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath12k: correct monitor-mode RX metadata handling
From: Baochen Qiang @ 2026-06-29 2:05 UTC (permalink / raw)
To: Sushant Butta, ath12k; +Cc: linux-wireless
In-Reply-To: <20260609064856.547032-1-sushant.butta@oss.qualcomm.com>
On 6/9/2026 2:48 PM, Sushant Butta wrote:
> This series fixes monitor-mode meta data handling in ath12k and trims dead code:
>
> Monitor mode delivers raw 802.11 frames should not set RX_FLAG_8023 flag,
> and populate peer/link metadata in ieee80211_rx_status for monitor MSDUs.
>
> Sushant Butta (2):
> wifi: ath12k: Skip setting RX_FLAG_8023 for Ethernet-II (DIX) frames
> in monitor mode
> wifi: ath12k: Skip peer link info update in rx_status for monitor
> MSDUs
>
> drivers/net/wireless/ath/ath12k/dp_mon.c | 70 +------------------
> drivers/net/wireless/ath/ath12k/dp_mon.h | 4 +-
> .../net/wireless/ath/ath12k/wifi7/dp_mon.c | 7 +-
> 3 files changed, 4 insertions(+), 77 deletions(-)
>
>
> base-commit: 38b2fb7d2df16f5801f7d88a4739942b95a5f6aa
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH rtw-next v3 2/3] wifi: rtlwifi: convert pci if-statement to ID table
From: Ping-Ke Shih @ 2026-06-29 2:01 UTC (permalink / raw)
To: William Hansen-Baird
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260626095648.1124924-3-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> Refactor the ASUSTek quirk logic from an if-statement to a standard
> rtl_aspm_quirks pci_device_id table. This allows future devices with
> the same quirk to be added more easily while avoiding a large if-chain.
>
> Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> drivers/net/wireless/realtek/rtlwifi/pci.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 38eca8d91581..44121203671c 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -31,6 +31,12 @@ static const u8 ac_to_hwq[] = {
> BK_QUEUE
> };
>
> +static const struct pci_device_id rtl_aspm_quirks[] = {
> + /* ASUSTek F441U/X555UQ */
> + { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
> + { }
nit: we can just '{}' (without a space).
> +};
> +
> static u8 _rtl_mac_to_hwqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
^ permalink raw reply
* RE: [PATCH rtw-next v3 1/3] wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
From: Ping-Ke Shih @ 2026-06-29 1:59 UTC (permalink / raw)
To: William Hansen-Baird
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260626095648.1124924-2-william.hansen.baird@gmail.com>
William Hansen-Baird <william.hansen.baird@gmail.com> wrote:
> commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
> adds code which sets ppsc->support_aspm to false in
> _rtl_pci_update_default_setting() in order to disable ASPM.
> This does not, however, disable ASPM. Rather, it disables driver
> control of ASPM, and blocks calls to rtl_pci_enable_aspm()
> and rtl_pci_disable_aspm().
>
> In some cases, the pci device supplied to the probe function has
> ASPM enabled. The code would therefore not disable ASPM, as it means to,
> but rather just leave it enabled.
> This was discovered through testing on a Razer Blade 14 2017.
>
> Implement a new __rtl_pci_disable_aspm(hw) function which does not check
> ppsc->support_aspm before disabling and call it from
> rtl_pci_disable_aspm().
>
> Then move the code added in the previous commit to rtl_pci_init_aspm() to
> allow adding a call to __rtl_pci_disable_aspm(hw).
> This makes sure ASPM is disabled while still disabling
> driver control of ASPM to block it from being enabled later.
>
> Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
A minor warning. Otherwise, looks good to me.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> @@ -330,10 +328,25 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
>
> static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
> {
> + struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
> struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> + struct rtl_priv *rtlpriv = rtl_priv(hw);
>
> _rtl_pci_update_default_setting(hw);
>
> + /*
.git/rebase-apply/patch:71: trailing whitespace.
/*
warning: 1 line adds whitespace errors.
> + * RTL8723BE found on some ASUSTek laptops, such as F441U and
> + * X555UQ with subsystem ID 11ad:1723 are known to output large
> + * amounts of PCIe AER errors during and after boot up, causing
> + * heavy lags, poor network throughput, and occasional lock-ups.
> + */
> + if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
> + (rtlpci->pdev->subsystem_vendor == 0x11ad &&
> + rtlpci->pdev->subsystem_device == 0x1723)) {
> + __rtl_pci_disable_aspm(hw);
> + ppsc->support_aspm = false;
> + }
> +
> if (ppsc->reg_rfps_level & RT_RF_PS_LEVEL_ALWAYS_ASPM) {
> /*Always enable ASPM & Clock Req. */
> rtl_pci_enable_aspm(hw);
> --
> 2.54.0
^ permalink raw reply
* RE: NIPA/wifibot disappeared
From: Ping-Ke Shih @ 2026-06-29 1:42 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <c7363a78c6324d519651c7729617b725@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Hi Johannes,
>
> Johannes Berg <johannes@sipsolutions.net> wrote:
> > It's on the netdev config, so perhaps a little pickier than it used to
> > be.
>
> Not sure how it considers -next tree. My patch with subject
> "[PATCH rtw-next] wifi: rtl8xxxu: 8723bu: ..." is treated as non-next tree [1].
>
> Could you help to update NIPA configuration? Or should I change to other
> proper tree selection of subject prefix?
>
> [1]
> https://patchwork.kernel.org/project/linux-wireless/patch/20260622015439.9621-1-pkshih@realtek.com
> /
It looks like NIPA misread "rtw-next" as "rtw" at the step of tree selection.
wifibot/tree_selection --> Clearly marked for rtw
Currently, we use "rtw" for current fix, and "rtw-next" for -next. However,
"rtw" is substring of "rtw-next". If this isn't a good choice, we can change
"rtw" to "rtw-current" or "rtw-fix".
Thanks
Ping-Ke
^ permalink raw reply
* [BUG] mt7921u: 6 GHz Multiple BSSID profile not reported during scan
From: Iris Burdick @ 2026-06-29 0:29 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 1382 bytes --]
Hi,
I believe I have found a problem with MediaTek MT7921 when scanning 6 GHz Multiple BSSID networks.
Hardware used:
Working system:
MediaTek MT7925 (PCI ID 14c3:7925)
Driver: mt7925e
Firmware Version: ____000000-20250305133013
Linux 6.12.94+deb13-amd64
iw 6.9
Non-working system:
MediaTek MT7921 (USB ID: 0e8d:7961)
Driver: mt7921u
Firmware Version: ____010000-20241106151045
Linux 6.12.93-v8+
iw 6.9
My access point:
TP-Link EAP783
6 GHz radio configured for IEEE 802.11ax/be mixed mode.
The configured SSID is "24c 6GHz"
The AP also advertises the transmitted BSSID "TP_TX_VAP" using IEEE 802.11 Multiple BSSID.
On the MT7925, scanning correctly produces two BSS entries:
SSID: 24c 6GHz
SSID: TP_TX_VAP
On the MT7921, scanning only reports
SSID: TP_TX_VAP
The configured SSID never appears.
Instead, the scan output contains
Unknown IE (71)
where the MT7925 correctly interprets the Multiple BSSID element.
The hidden SSID is clearly embedded inside the raw IE:
Unknown IE (71):
04 00 30 53 02 11 04 00 08
32 34 63 20 36 47 48 7a
...
which decodes to the ASCII string
24c 6GHz
you can reproduce the issue with:
sudo iw dev <interface> scan -u freq 6215
I've attached the scan output from both systems for comparison.
Please let me know if any additional debugging information (firmware versions, dmesg, trace logs, etc.) would be useful.
Thanks,
Iris.
[-- Attachment #1.2: Type: text/html, Size: 3643 bytes --]
[-- Attachment #2: mt7925-scan.txt --]
[-- Type: text/plain, Size: 11815 bytes --]
BSS 20:36:26:df:b0:61(on wlp7s0) -- associated
last seen: 49994.804s [boottime]
TSF: 14540486357365 usec (168d, 07:01:26)
freq: 5320.0
beacon interval: 100 TUs
capability: ESS Privacy SpectrumMgmt ShortSlotTime (0x0511)
signal: -49.00 dBm
last seen: 44 ms ago
Information elements from Probe Response frame:
SSID: 24c
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 64
Country: DE Environment: bogus
Channels [36 - 64] @ 23 dBm
Channels [100 - 140] @ 30 dBm
Power constraint: 0 dB
TPC report: TX power: 21 dBm
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
HT capabilities:
Capabilities: 0x9ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-15
HT operation:
* primary channel: 64
* secondary channel offset: below
* STA channel width: any
* RIFS: 0
* HT protection: no
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Extended capabilities:
* Extended Channel Switching
* SSID List
* Operating Mode Notification
* Max Number Of MSDUs In A-MSDU is unlimited
VHT capabilities:
VHT Capabilities (0x3389e9b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
SU Beamformer
MU Beamformer
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
VHT extended NSS: supported
VHT operation:
* channel width: 1 (80 MHz)
* center freq segment 1: 58
* center freq segment 2: 0
* VHT basic MCS set: 0xfffc
Transmit Power Envelope:
* Local Maximum Transmit Power For 20 MHz: 23 dBm
* Local Maximum Transmit Power For 40 MHz: 23 dBm
* Local Maximum Transmit Power For 80 MHz: 23 dBm
Unknown IE (201): 10 0d 86 35 ff 22 36 26 df b0 62 e1 c2 26 af 4c 14 ff 22 36 26 df b0 63 cf 39 a2 99 44 14
Unknown IE (244): 01 05
HE capabilities:
HE MAC Capabilities (0x01091a081040):
+HTC HE Supported
Dynamic BA Fragementation Level: 1
Minimum Payload size of 128 bytes: 1
BSR
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x046340881f419d1c110a00):
HE40/HE80/5GHz
Punctured Preamble RX: 3
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
Full Bandwidth UL MU-MIMO
DCM Max Constellation Rx: 1
SU Beamformer
SU Beamformee
MU Beamformer
Beamformee STS <= 80Mhz: 7
Sounding Dimensions <= 80Mhz: 1
Ng = 16 SU Feedback
Codebook Size SU Feedback
Triggered SU Beamforming Feedback
Triggered MU Beamforming Feedback
Triggered CQI Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
HE ER SU PPDU 4x HE-LTF 0.8us GI
HE ER SU PPDU 1x HE-LTF 0.8us GI
Non-Triggered CQI Feedback
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
PPE Threshold 0x79 0x1c 0xc7 0x71 0x1c 0xc7 0x71
Unknown Extension ID (36): f4 3f 00 24 fc ff
Unknown Extension ID (39): 03
Unknown Extension ID (38): 0e 03 a4 ff 27 a4 ff 42 43 ff 62 32 ff
Unknown Extension ID (108): 17 00 e0 03 01 e0 18 77 d8 12 00 22 22 22
Unknown Extension ID (106): 04 11 00 00 00
Vendor specific: OUI 8c:fd:f0, data: 01 01 02 01 00 02 01 01 03 03 01 01 00 04 01 01 09 02 03 03
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Vendor specific: OUI 8c:fd:f0, data: 04 01 01 00
BSS 22:36:26:df:b0:63(on wlp7s0)
last seen: 49994.702s [boottime]
TSF: 14541467033660 usec (168d, 07:17:47)
freq: 6215.0
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -54.00 dBm
last seen: 148 ms ago
SSID: 24c 6GHz
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
Country: DE Environment: bogus
Extension ID: 201 Regulatory Class: 131 Coverage class: 0 (up to 0m)
Channels [33 - 93] @ 0 dBm
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: SAE
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC MFP-required MFP-capable (0x00cc)
Extended capabilities:
* Extended Channel Switching
* Multiple BSSID
* SSID List
* Operating Mode Notification
* 80
* 83
Unknown IE (244): 21 05
HE capabilities:
HE MAC Capabilities (0x01091a081040):
+HTC HE Supported
Dynamic BA Fragementation Level: 1
Minimum Payload size of 128 bytes: 1
BSR
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c63408802099c1c110a00):
HE40/HE80/5GHz
HE160/5GHz
Punctured Preamble RX: 3
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
Full Bandwidth UL MU-MIMO
DCM Max Constellation Rx: 1
SU Beamformer
MU Beamformer
Sounding Dimensions <= 80Mhz: 1
Sounding Dimensions > 80Mhz: 1
Triggered SU Beamforming Feedback
Triggered MU Beamforming Feedback
Triggered CQI Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
HE ER SU PPDU 4x HE-LTF 0.8us GI
HE ER SU PPDU 1x HE-LTF 0.8us GI
Non-Triggered CQI Feedback
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
PPE Threshold 0x79 0x1c 0xc7 0x71 0x1c 0xc7 0x71
Unknown Extension ID (36): f4 3f 02 30 fc ff 35 03 37 2f 01
Unknown Extension ID (39): 03
Unknown Extension ID (38): 0c 03 a4 ff 27 a4 ff 42 43 ff 62 32 ff
Unknown Extension ID (59): b8 36
Vendor specific: OUI 8c:fd:f0, data: 01 01 02 01 00 02 01 01 03 03 01 01 00 04 01 01 09 02 03 03
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Vendor specific: OUI 8c:fd:f0, data: 04 01 01 00
Extended supported rates: 61.5*
BSS 22:36:26:df:b0:62(on wlp7s0)
last seen: 49994.702s [boottime]
TSF: 14541467033660 usec (168d, 07:17:47)
freq: 6215.0
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -55.00 dBm
last seen: 148 ms ago
SSID: TP_TX_VAP
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
Country: DE Environment: bogus
Extension ID: 201 Regulatory Class: 131 Coverage class: 0 (up to 0m)
Channels [33 - 93] @ 0 dBm
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: OWE
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC MFP-required MFP-capable (0x00cc)
Unknown IE (71): 04 00 30 53 02 11 04 00 08 32 34 63 20 36 47 48 7a 55 03 01 01 00 32 01 fb 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 f4 02 21 05
Extended capabilities:
* Extended Channel Switching
* Multiple BSSID
* SSID List
* Operating Mode Notification
* 80
* 83
Unknown IE (244): 01 05
HE capabilities:
HE MAC Capabilities (0x01091a081040):
+HTC HE Supported
Dynamic BA Fragementation Level: 1
Minimum Payload size of 128 bytes: 1
BSR
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c63408802099c1c110a00):
HE40/HE80/5GHz
HE160/5GHz
Punctured Preamble RX: 3
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
Full Bandwidth UL MU-MIMO
DCM Max Constellation Rx: 1
SU Beamformer
MU Beamformer
Sounding Dimensions <= 80Mhz: 1
Sounding Dimensions > 80Mhz: 1
Triggered SU Beamforming Feedback
Triggered MU Beamforming Feedback
Triggered CQI Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
HE ER SU PPDU 4x HE-LTF 0.8us GI
HE ER SU PPDU 1x HE-LTF 0.8us GI
Non-Triggered CQI Feedback
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
PPE Threshold 0x79 0x1c 0xc7 0x71 0x1c 0xc7 0x71
Unknown Extension ID (36): f4 3f 02 30 fc ff 35 03 37 2f 01
Unknown Extension ID (39): 03
Unknown Extension ID (38): 0c 03 a4 ff 27 a4 ff 42 43 ff 62 32 ff
Unknown Extension ID (59): b8 36
Vendor specific: OUI 8c:fd:f0, data: 01 01 02 01 00 02 01 01 03 03 01 01 00 04 01 01 09 02 03 03
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Vendor specific: OUI 8c:fd:f0, data: 04 01 01 00
[-- Attachment #3: mt7921-scan.txt --]
[-- Type: text/plain, Size: 3505 bytes --]
BSS 22:36:26:df:b0:62(on wlan1)
last seen: 20720.771s [boottime]
TSF: 14541475430460 usec (168d, 07:17:55)
freq: 6215.0
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -59.00 dBm
last seen: 180 ms ago
SSID: TP_TX_VAP
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
Country: DE Environment: bogus
Extension ID: 201 Regulatory Class: 131 Coverage class: 0 (up to 0m)
Channels [33 - 93] @ 0 dBm
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: OWE
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC MFP-required MFP-capable (0x00cc)
Unknown IE (71): 04 00 30 53 02 11 04 00 08 32 34 63 20 36 47 48 7a 55 03 01 01 00 32 01 fb 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 f4 02 21 05
Extended capabilities:
* Extended Channel Switching
* Multiple BSSID
* SSID List
* Operating Mode Notification
* 80
* 83
Unknown IE (244): 01 05
HE capabilities:
HE MAC Capabilities (0x01091a081040):
+HTC HE Supported
Dynamic BA Fragementation Level: 1
Minimum Payload size of 128 bytes: 1
BSR
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c63408802099c1c110a00):
HE40/HE80/5GHz
HE160/5GHz
Punctured Preamble RX: 3
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
Full Bandwidth UL MU-MIMO
DCM Max Constellation Rx: 1
SU Beamformer
MU Beamformer
Sounding Dimensions <= 80Mhz: 1
Sounding Dimensions > 80Mhz: 1
Triggered SU Beamforming Feedback
Triggered MU Beamforming Feedback
Triggered CQI Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
HE ER SU PPDU 4x HE-LTF 0.8us GI
HE ER SU PPDU 1x HE-LTF 0.8us GI
Non-Triggered CQI Feedback
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
PPE Threshold 0x79 0x1c 0xc7 0x71 0x1c 0xc7 0x71
Unknown Extension ID (36): f4 3f 02 30 fc ff 35 03 37 2f 01
Unknown Extension ID (39): 03
Unknown Extension ID (38): 0c 03 a4 ff 27 a4 ff 42 43 ff 62 32 ff
Unknown Extension ID (59): b8 36
Vendor specific: OUI 8c:fd:f0, data: 01 01 02 01 00 02 01 01 03 03 01 01 00 04 01 01 09 02 03 03
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Vendor specific: OUI 8c:fd:f0, data: 04 01 01 00
^ permalink raw reply
* Re: [PATCH wireless-next v3 00/33] wifi: mm81x: add mm81x driver
From: Lachlan Hodges @ 2026-06-29 0:13 UTC (permalink / raw)
To: johannes
Cc: arien.judge, dan.callaghan, ayman.grais, linux-wireless,
Andrew Pope, Bassem Dawood, Chetan Mistry, James Herbert,
Sahand Maleki, Simon Wadsworth
In-Reply-To: <20260626063014.1275235-1-lachlan.hodges@morsemicro.com>
Hi,
I forgot to attach the firmware and board files to the cover letter.
They can be found below:
BCFS:
https://github.com/MorseMicro/morse-firmware/tree/65ca270dac4ad70d009db6c50b26502177aae9e4/bcf/morsemicro
Firmware:
https://github.com/MorseMicro/morse-firmware/blob/65ca270dac4ad70d009db6c50b26502177aae9e4/firmware/mm8108b2-rl.bin
lachlan
^ permalink raw reply
* Re: [PATCH wireless] wifi: mac80211: clear beaconing state in ieee80211_do_stop()
From: Hojun Choi @ 2026-06-28 14:13 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, linux-kernel, Deepak Karn,
syzbot+ca7a2759caaa6cd4e3db, Hojun Choi
In-Reply-To: <20260628130802.7698-1-ghwns6743@gmail.com>
Following up with the concrete path, since the question is whether
cfg80211_leave() already covers this. It does not for AP start failure:
ieee80211_start_ap() sets enable_beacon before its fail-able steps, but
its error path (cfg.c:1930) only releases the channel, never clearing it
(unlike the IBSS/mesh paths), while cfg80211 leaves ap.beacon_interval at
0. A later interface-down then makes ___cfg80211_stop_ap() short-circuit
(-ENOENT, net/wireless/ap.c:30) and skip the stop_ap clear, so
ieee80211_do_stop() runs with enable_beacon still set. I could not get a
driver to fail start_ap() there, so this is by inspection, not a
reproducer.
I can fold this into the commit message in a v2, or instead fix the
producer by clearing enable_beacon on the start_ap() error path
(mirroring IBSS/mesh) - whichever you prefer. I used do_stop() since
you suggested it might need to clear that bit.
Thanks,
Hojun
^ permalink raw reply
* [PATCH wireless] wifi: mac80211: clear beaconing state in ieee80211_do_stop()
From: Hojun Choi @ 2026-06-28 13:08 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, linux-kernel, Deepak Karn,
syzbot+ca7a2759caaa6cd4e3db, Hojun Choi
ieee80211_do_stop() zeroes vif.bss_conf.beacon_int but, unlike
ieee80211_stop_ap(), ieee80211_ibss_disconnect() and
ieee80211_stop_mesh(), leaves enable_beacon set and the
SDATA_STATE_OFFCHANNEL_BEACON_STOPPED bit pending. cfg80211 rejects a
beacon interval below 10, so a zero interval comes from this teardown,
not from userspace.
do_stop() clears SDATA_STATE_RUNNING first, so nothing acts on the stale
state while the interface is down. But do_open() re-sets RUNNING without
restoring beacon_int or clearing enable_beacon and the bit, so the state
survives a down/up cycle. A later ieee80211_offchannel_return() on scan
completion then consumes the stale bit and re-enables beaconing while
beacon_int is still 0, and drivers arming a beacon timer from the
interval divide by zero. syzbot reported this as a divide error in
mac80211_hwsim_link_info_changed(); the exact sequence that leaves
do_stop() with beaconing still enabled was not reproduced.
Clear enable_beacon and the bit in ieee80211_do_stop() as well,
mirroring the other teardown paths, so the state cannot outlive the
interface. do_stop() warns on a vif that still has valid links, so MLD
links are already torn down here and only the deflink beacon_int is
zeroed; clearing the deflink enable_beacon is sufficient.
Fixes: d6a83228823f ("mac80211: track enable_beacon explicitly")
Reported-by: syzbot+ca7a2759caaa6cd4e3db@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ca7a2759caaa6cd4e3db
Link: https://lore.kernel.org/all/20251205153502.273426-1-dkarn@redhat.com/
Signed-off-by: Hojun Choi <ghwns6743@gmail.com>
---
net/mac80211/iface.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 086272c3ec08..c070d47cb631 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -719,6 +719,10 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata, bool going_do
sdata->vif.bss_conf.beacon_int = 0;
+ /* mirror stop_ap()/IBSS/mesh: also clear the beaconing state */
+ sdata->vif.bss_conf.enable_beacon = false;
+ clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
+
/*
* If the interface goes down while suspended, presumably because
* the device was unplugged and that happens before our resume,
--
2.54.0
^ permalink raw reply related
* [PATCH] wifi: mt76: mt7996: fix TX DMA mapping leak for ADDBA-req frames
From: Yang Liu @ 2026-06-28 10:11 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee; +Cc: shayne.chen, sean.wang, linux-wireless, stable
mt7996 hands the firmware a HW MAC-TXP for ADDBA-req action frames
(MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but the chip is a
FW-TXP device, so on TX completion mt76_connac_txp_skb_unmap() decodes
the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the
fw_txp.nbuf byte aliases the high byte of the TID word
(MT_TXP1_TID_ADDBA, GENMASK(14, 12)), which is always zero, so the
unmap loop runs zero times and buf[1] (the skb DMA mapping) is never
unmapped. mt7996_tx_prepare_skb() also sets buf[1].skip_unmap
unconditionally, so the generic mt76 DMA-ring cleanup skips it as well.
Each ADDBA req therefore leaks one TX DMA mapping, i.e. roughly one per
(re)association. When WED is enabled the mt76 DMA device bounces these
mappings through the WED swiotlb pool, so under continuous client
reconnect churn the pool is exhausted after ~1-2 days, after which DMA
mapping fails for WED, the WiFi MCU and other on-SoC consumers.
Only set buf[1].skip_unmap on the FW-TXP path. For MAC-TXD frames
leave it clear so mt76_dma_tx_cleanup_idx() unmaps buf[1]. The FW
unmap is a no-op for these frames (nbuf reads 0), so there is no double
free.
Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for
AddBA Request")
Cc: stable@vger.kernel.org
Assisted-by: Claude-Code:claude-opus-4-8
Signed-off-by: X <50459973+ly4096x@users.noreply.github.com>
---
Tested on a Banana Pi R4 Pro (MT7988A, MT7996/BE14, WED enabled, 6.18.35):
under a continuous client (re)association reproducer (~51 reassoc/min),
/sys/kernel/debug/swiotlb/io_tlb_used grew ~25 slots/min before this
patch (steady leak; pool exhaustion and the resulting DMA failures after
~1-2 days) and is flat after it, with no double free.
drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index 0eebc81..962dad4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -1010,6 +1010,7 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev,
void *txwi_ptr,
struct mt76_txwi_cache *t;
int id, i, pid, nbuf = tx_info->nbuf - 1;
bool is_8023 = info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP;
+ bool mac_txd;
__le32 *ptr = (__le32 *)txwi_ptr;
u8 *txwi = (u8 *)txwi_ptr;
u8 link_id;
@@ -1096,7 +1097,8 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev,
void *txwi_ptr,
/* MT7996 and MT7992 require driver to provide the MAC TXP for AddBA
* req
*/
- if (le32_to_cpu(ptr[7]) & MT_TXD7_MAC_TXD) {
+ mac_txd = le32_to_cpu(ptr[7]) & MT_TXD7_MAC_TXD;
+ if (mac_txd) {
u32 val, mac_txp_size = sizeof(struct mt76_connac_hw_txp);
ptr = (__le32 *)(txwi + MT_TXD_SIZE);
@@ -1167,7 +1169,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev
*mdev, void *txwi_ptr,
/* pass partial skb header to fw */
tx_info->buf[1].len = MT_CT_PARSE_LEN;
- tx_info->buf[1].skip_unmap = true;
+ /* MAC-TXD (ADDBA-req) frames use a HW MAC-TXP that the fw-txp
+ * mt76_connac_txp_skb_unmap() path does not unmap; free buf[1] via the
+ * DMA-ring cleanup for them instead.
+ */
+ tx_info->buf[1].skip_unmap = !mac_txd;
tx_info->nbuf = MT_CT_DMA_BUF_NUM;
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] wifi: mt76: mt7996: fix TX DMA mapping leak for ADDBA-req frames
From: Yang Liu @ 2026-06-28 10:18 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee; +Cc: shayne.chen, sean.wang, linux-wireless, stable
In-Reply-To: <CAMt2zv5c0cYzfe0RQ5AfoUdm+b4bAshgjCs23NjFBhQXDKLniQ@mail.gmail.com>
MT7996 hands the firmware a HW MAC-TXP for ADDBA-req action frames
(MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but the chip is a
FW-TXP device, so on TX completion mt76_connac_txp_skb_unmap() decodes
the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the
fw_txp.nbuf byte aliases the high byte of the TID word
(MT_TXP1_TID_ADDBA, GENMASK(14, 12)), which is always zero, so the
unmap loop runs zero times and buf[1] (the skb DMA mapping) is never
unmapped. mt7996_tx_prepare_skb() also sets buf[1].skip_unmap
unconditionally, so the generic mt76 DMA-ring cleanup skips it as well.
Each ADDBA req therefore leaks one TX DMA mapping, i.e. roughly one per
(re)association. When WED is enabled the mt76 DMA device bounces these
mappings through the WED swiotlb pool, so under continuous client
reconnect churn the pool is exhausted after ~1-2 days, after which DMA
mapping fails for WED, the WiFi MCU and other on-SoC consumers.
Only set buf[1].skip_unmap on the FW-TXP path. For MAC-TXD frames
leave it clear so mt76_dma_tx_cleanup_idx() unmaps buf[1]. The FW
unmap is a no-op for these frames (nbuf reads 0), so there is no double
free.
Fixes: cb6ebbdffef2 ("wifi: mt76: mt7996: support writing MAC TXD for
AddBA Request")
Cc: stable@vger.kernel.org
Assisted-by: Claude-Code:claude-opus-4-8
Signed-off-by: Yang Liu <liu.y@nyu.edu>
---
Tested on a Banana Pi R4 Pro (MT7988A, MT7996/BE14, WED enabled, 6.18.35):
under a continuous client (re)association reproducer (~51 reassoc/min),
/sys/kernel/debug/swiotlb/io_tlb_used grew ~25 slots/min before this
patch (steady leak; pool exhaustion and the resulting DMA failures after
~1-2 days) and is flat after it, with no double free.
drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
index 0eebc81..962dad4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
@@ -1010,6 +1010,7 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev,
void *txwi_ptr,
struct mt76_txwi_cache *t;
int id, i, pid, nbuf = tx_info->nbuf - 1;
bool is_8023 = info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP;
+ bool mac_txd;
__le32 *ptr = (__le32 *)txwi_ptr;
u8 *txwi = (u8 *)txwi_ptr;
u8 link_id;
@@ -1096,7 +1097,8 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev,
void *txwi_ptr,
/* MT7996 and MT7992 require driver to provide the MAC TXP for AddBA
* req
*/
- if (le32_to_cpu(ptr[7]) & MT_TXD7_MAC_TXD) {
+ mac_txd = le32_to_cpu(ptr[7]) & MT_TXD7_MAC_TXD;
+ if (mac_txd) {
u32 val, mac_txp_size = sizeof(struct mt76_connac_hw_txp);
ptr = (__le32 *)(txwi + MT_TXD_SIZE);
@@ -1167,7 +1169,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev
*mdev, void *txwi_ptr,
/* pass partial skb header to fw */
tx_info->buf[1].len = MT_CT_PARSE_LEN;
- tx_info->buf[1].skip_unmap = true;
+ /* MAC-TXD (ADDBA-req) frames use a HW MAC-TXP that the fw-txp
+ * mt76_connac_txp_skb_unmap() path does not unmap; free buf[1] via the
+ * DMA-ring cleanup for them instead (see commit message).
+ */
+ tx_info->buf[1].skip_unmap = !mac_txd;
tx_info->nbuf = MT_CT_DMA_BUF_NUM;
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH net v2] wifi: mac80211: fix memory leak in ieee80211_register_hw()
From: Dawei Feng @ 2026-06-28 9:59 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, linux-kernel, zilin, jianhao.xu, Dawei Feng,
stable
If kmemdup() fails while copying supported band structures, the error
path jumps to fail_rate. This skips rate_control_deinitialize() and
leaks the initialized local->rate_ctrl.
Fix this by adding a fail_band label that shares the rate-control cleanup
path before falling through to the remaining teardown.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. 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 mac80211 device/driver combination to test with, no runtime
testing was able to be performed.
Fixes: 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support")
Cc: stable@vger.kernel.org
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
Changes in v2:
- Add a fail_band label for the band-copy failure path instead of jumping
directly to fail_wiphy_register.
net/mac80211/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index f47dd58770ad..dba66dd964af 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1599,7 +1599,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
sband = kmemdup(sband, sizeof(*sband), GFP_KERNEL);
if (!sband) {
result = -ENOMEM;
- goto fail_rate;
+ goto fail_band;
}
wiphy_dbg(hw->wiphy, "copying sband (band %d) due to VHT EXT NSS BW flag\n",
@@ -1675,6 +1675,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
#endif
wiphy_unregister(local->hw.wiphy);
fail_wiphy_register:
+ fail_band:
rtnl_lock();
rate_control_deinitialize(local);
ieee80211_remove_interfaces(local);
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] wifi: mt76: mt7996: register a LED classdev for every band
From: Petr Wozniak @ 2026-06-28 9:53 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, linux-wireless, Petr Wozniak
In-Reply-To: <20260628095313.7790-1-petr.wozniak@gmail.com>
The per-band LED callbacks (brightness_set/blink_set) were only assigned
to the primary PHY (dev->mphy) in mt7996_init_wiphy(). The 5/6 GHz bands
are brought up later through mt7996_register_phy() ->
mt7996_init_wiphy_band(), which never set those callbacks, so
mt76_led_init() bailed out early for them and only the 2.4 GHz LED was
ever registered.
The hardware path is already per band: mt7996_led_set_config() indexes
MT_LED_EN()/MT_LED_CTRL()/MT_LED_TX_BLINK() by mphy->band_idx, so per-band
hardware TX-blink works as soon as the classdev exists.
Move the callback assignment into mt7996_init_wiphy_band(), which runs for
every band, so a LED classdev is registered for each band.
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
.../net/wireless/mediatek/mt76/mt7996/init.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
index d6f9aa1ab..b77b85654 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c
@@ -472,6 +472,18 @@ mt7996_init_wiphy_band(struct ieee80211_hw *hw, struct mt7996_phy *phy)
mt7996_set_stream_vht_txbf_caps(phy);
mt7996_set_stream_he_eht_caps(phy);
mt7996_init_txpower(phy);
+
+ /* Register a LED classdev for every band, not just the primary one.
+ * Under single-wiphy MLO the 5/6 GHz bands are brought up through
+ * mt7996_register_phy(); without these callbacks mt76_led_init() skips
+ * them and only the 2.4 GHz LED is exposed. The hardware TX-blink path
+ * is already indexed by band_idx, so per-band blink works once the
+ * classdev exists.
+ */
+ if (IS_ENABLED(CONFIG_MT76_LEDS)) {
+ phy->mt76->leds.cdev.brightness_set = mt7996_led_set_brightness;
+ phy->mt76->leds.cdev.blink_set = mt7996_led_set_blink;
+ }
}
static void
@@ -542,12 +554,6 @@ mt7996_init_wiphy(struct ieee80211_hw *hw, struct mtk_wed_device *wed)
hw->max_tx_fragments = 4;
wiphy->txq_memory_limit = 32 << 20; /* 32 MiB */
- /* init led callbacks */
- if (IS_ENABLED(CONFIG_MT76_LEDS)) {
- dev->mphy.leds.cdev.brightness_set = mt7996_led_set_brightness;
- dev->mphy.leds.cdev.blink_set = mt7996_led_set_blink;
- }
-
wiphy->max_scan_ssids = 4;
wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] wifi: mt76: share the throughput LED trigger across bands
From: Petr Wozniak @ 2026-06-28 9:53 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, linux-wireless, Petr Wozniak
In-Reply-To: <20260628095313.7790-1-petr.wozniak@gmail.com>
ieee80211_create_tpt_led_trigger() creates one trigger per ieee80211_hw
and returns NULL with a WARN_ON() if called again for the same hw.
Under the single-wiphy MLO model each band registers its own LED classdev
for the same hw, and the bands can be initialised in any order. Create the
trigger on the first mt76_led_init() call, stash it on the primary phy's
classdev and let the other bands reuse it. This avoids the WARN_ON() splat
and gives every band the same throughput trigger regardless of init order.
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 13c4e8abe..e56fb95ce 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -228,11 +228,19 @@ static int mt76_led_init(struct mt76_phy *phy)
wiphy_name(hw->wiphy));
phy->leds.cdev.name = phy->leds.name;
- phy->leds.cdev.default_trigger =
- ieee80211_create_tpt_led_trigger(hw,
- IEEE80211_TPT_LEDTRIG_FL_RADIO,
- mt76_tpt_blink,
- ARRAY_SIZE(mt76_tpt_blink));
+ /* The throughput trigger is created once per ieee80211_hw. Under
+ * single-wiphy MLO every band registers its own LED classdev for the
+ * same hw and the bands can come up in any order, so create the trigger
+ * on the first call, stash it on the primary phy and let the other bands
+ * reuse it; calling it again would trip a WARN_ON().
+ */
+ if (!dev->phy.leds.cdev.default_trigger)
+ dev->phy.leds.cdev.default_trigger =
+ ieee80211_create_tpt_led_trigger(hw,
+ IEEE80211_TPT_LEDTRIG_FL_RADIO,
+ mt76_tpt_blink,
+ ARRAY_SIZE(mt76_tpt_blink));
+ phy->leds.cdev.default_trigger = dev->phy.leds.cdev.default_trigger;
dev_info(dev->dev,
"registering led '%s'\n", phy->leds.name);
--
2.51.0
^ permalink raw reply related
* [PATCH 0/2] wifi: mt76: fix per-band LEDs under single-wiphy MLO
From: Petr Wozniak @ 2026-06-28 9:53 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee
Cc: Shayne Chen, Sean Wang, linux-wireless, Petr Wozniak
On MT7996 (and other single-wiphy MLO mt76 devices) only the 2.4 GHz LED
was ever usable: the 5/6 GHz band LEDs stayed dark and a WARN_ON() was hit
during probe.
Two issues are involved:
1. mt76_led_init() calls ieee80211_create_tpt_led_trigger() for every band,
but that helper supports only one trigger per ieee80211_hw and
WARN_ON()s + returns NULL on the second call, so the secondary bands got
a NULL default trigger.
2. mt7996 assigned the LED brightness_set/blink_set callbacks only to the
primary PHY, so mt76_led_init() bailed out early for the 5/6 GHz bands
and never registered their LED classdevs.
Patch 1 shares the throughput trigger across all bands; patch 2 registers a
LED classdev for every band. With both applied, all three band LEDs
(mt76-phy0/1/2) come up and blink on their band's traffic.
Tested on a BPI-R4 (MT7996/BE14): all three per-band LEDs register at boot
with no WARN_ON(), and each blinks on its own band's activity (verified
with single-band and MLO clients).
Petr Wozniak (2):
wifi: mt76: share the throughput LED trigger across bands
wifi: mt76: mt7996: register a LED classdev for every band
drivers/net/wireless/mediatek/mt76/mac80211.c | 18 +++++++++++++-----
.../net/wireless/mediatek/mt76/mt7996/init.c | 18 ++++++++++++------
2 files changed, 25 insertions(+), 11 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH] wifi: carl9170: reject mismatched command response lengths
From: Yousef Alhouseen @ 2026-06-28 9:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-wireless, linux-kernel, stable, syzbot+5c1ca6ccaa1215781cac,
Yousef Alhouseen
The firmware response length is controlled by the USB device. Although
carl9170_cmd_callback() detects when it differs from the output buffer
length, the function falls through and copies the entire response into
that buffer. Callers commonly provide stack objects, so a malformed
response can overwrite the kernel stack.
Return after scheduling device recovery. This also preserves the stated
behavior of leaving the command incomplete so that its waiter times out
and clears the pending output buffer.
Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
Cc: stable@vger.kernel.org
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/net/wireless/ath/carl9170/rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
index 6833430130f4..ea3f435fb64c 100644
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -145,6 +145,7 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer)
* and we get a stack trace from there.
*/
carl9170_restart(ar, CARL9170_RR_INVALID_RSP);
+ return;
}
spin_lock(&ar->cmd_lock);
--
2.54.0
^ permalink raw reply related
* rtw89: RTL8852BE P2P-device iftype and STA+P2P interface combination
From: Doug Brewer @ 2026-06-28 6:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Ping-Ke Shih
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?
2. would advertising a managed + P2P-client interface combination
(single channel) be feasible on the current rtw89?
3. is MCC (#channels > 1) on the roadmap, or considered out of scope?
Regards,
Doug
^ permalink raw reply
* Re: [PATCH] fix: ath11k: ath11k_ahb_fw_resources_init: fix device_node reference leak on setup failure
From: WenTao Liang @ 2026-06-28 4:02 UTC (permalink / raw)
To: Kalle Valo, linux-wireless; +Cc: Jeff Johnson, stable, linux-kernel
In-Reply-To: <20260626153619.52954-1-vulab@iscas.ac.cn>
> 2026年6月26日 23:36，WenTao Liang <vulab@iscas.ac.cn> 写道：
>
> of_get_child_by_name acquires a device_node reference. When the
> subsequent ath11k_ahb_setup_msa_resources call fails, the function
> returns immediately without calling of_node_put, leaking the node
> reference.
>
> Add of_node_put before returning on the setup failure error path.
>
> Cc: stable@vger.kernel.org
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
> ---
> drivers/net/wireless/ath/ath11k/ahb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
> index 08d3a0c8f105..8a08275db40a 100644
> --- a/drivers/net/wireless/ath/ath11k/ahb.c
> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
> @@ -996,6 +996,7 @@ static int ath11k_ahb_fw_resources_init(struct ath11k_base *ab)
> ret = ath11k_ahb_setup_msa_resources(ab);
> if (ret) {
> ath11k_err(ab, "failed to setup msa resources\n");
> + of_node_put(node);
> return ret;
> }
>
> --
> 2.39.5 (Apple Git-154)
Please ignore this patch. I will resend a proper version after
learning the kernel submission process.
Apologies for the noise.
Best regards,
WenTao Liang
^ permalink raw reply
* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: Bjorn Andersson @ 2026-06-28 3:08 UTC (permalink / raw)
To: Konrad Dybcio
Cc: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <38aceb33-b28e-4994-b277-de070b6dae2b@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 01:20:25PM +0200, Konrad Dybcio wrote:
> On 6/25/26 4:10 PM, George Moussalem via B4 Relay wrote:
> > From: George Moussalem <george.moussalem@outlook.com>
> >
> > Add support to bring up the M0 core of the bluetooth subsystem found in
> > the IPQ5018 SoC.
> >
> > The signed firmware loaded is authenticated by TrustZone. If successful,
> > the M0 core boots the firmware and the peripheral is taken out of reset
> > using a Secure Channel Manager call to TrustZone.
> >
> > Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> > ---
>
> Can this not fit inside the existing PAS driver?
>
While the start/stop SCM calls look the same, this doesn't follow any of
the surrounding concepts. So I think this should follow the other
non-remoteproc uses of mdt_loader and scm directly instead.
Regards,
Bjorn
> Konrad
^ permalink raw reply
* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: Bjorn Andersson @ 2026-06-28 3:07 UTC (permalink / raw)
To: george.moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Konrad Dybcio, Mathieu Poirier,
Philipp Zabel, linux-block, linux-kernel, linux-mmc, devicetree,
linux-wireless, ath10k, linux-arm-msm, linux-bluetooth, netdev,
linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-2-d999be0e04f7@outlook.com>
On Thu, Jun 25, 2026 at 06:10:06PM +0400, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add support to bring up the M0 core of the bluetooth subsystem found in
> the IPQ5018 SoC.
>
> The signed firmware loaded is authenticated by TrustZone. If successful,
> the M0 core boots the firmware and the peripheral is taken out of reset
> using a Secure Channel Manager call to TrustZone.
>
The remoteproc framework deals with life cycle management of
coprocessors, but you don't want that - you want the BT driver to own
the life cycle.
Further, the fact that you split this in "BT" and "remoteproc", results
in you having two representations in DeviceTree and in the device model
for the same hardware.
I know we have examples of this in the kernel already, but they are all
racy...
Please see if you can embed the firmware loading, authentication and
PAS calls directly into the BT driver - to have a single entity managing
the life cycle of your M0 processor.
Regards,
Bjorn
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> drivers/remoteproc/Kconfig | 12 ++
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/qcom_m0_btss_pil.c | 261 ++++++++++++++++++++++++++++++++++
> 3 files changed, 274 insertions(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c521c744e7db..6b52f78f1427 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -163,6 +163,18 @@ config PRU_REMOTEPROC
> processors on various TI SoCs. It's safe to say N here if you're
> not interested in the PRU or if you are unsure.
>
> +config QCOM_M0_BTSS_PIL
> + tristate "Qualcomm M0 BTSS Peripheral Image Loader"
> + depends on OF && ARCH_QCOM
> + select QCOM_MDT_LOADER
> + select QCOM_RPROC_COMMON
> + select QCOM_SCM
> + help
> + Say y here to support the Secure Peripheral Imager Loader for the
> + Qualcomm Bluetooth Subsystem running on the M0 remote processor found
> + in the IPQ5018 SoC. The M0 core is started and stopped using a
> + Secure Channel Manager call to TrustZone.
> +
> config QCOM_PIL_INFO
> tristate
>
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 1c7598b8475d..df80faf8d0df 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> obj-$(CONFIG_MESON_MX_AO_ARC_REMOTEPROC)+= meson_mx_ao_arc.o
> obj-$(CONFIG_PRU_REMOTEPROC) += pru_rproc.o
> +obj-$(CONFIG_QCOM_M0_BTSS_PIL) += qcom_m0_btss_pil.o
> obj-$(CONFIG_QCOM_PIL_INFO) += qcom_pil_info.o
> obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
> diff --git a/drivers/remoteproc/qcom_m0_btss_pil.c b/drivers/remoteproc/qcom_m0_btss_pil.c
> new file mode 100644
> index 000000000000..7168e270e4d4
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_m0_btss_pil.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026 The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/elf.h>
> +#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +#include <linux/soc/qcom/mdt_loader.h>
> +
> +#include "qcom_common.h"
> +
> +#define BTSS_PAS_ID 0xc
> +
> +struct m0_btss {
> + struct device *dev;
> + phys_addr_t mem_phys;
> + phys_addr_t mem_reloc;
> + void __iomem *mem_region;
> + size_t mem_size;
> + struct reset_control *btss_reset;
> +};
> +
> +static int m0_btss_start(struct rproc *rproc)
> +{
> + int ret;
> +
> + if (!qcom_scm_pas_supported(BTSS_PAS_ID)) {
> + dev_err(rproc->dev.parent,
> + "PAS is not available for peripheral: 0x%x\n",
> + BTSS_PAS_ID);
> + return -ENODEV;
> + }
> +
> + ret = qcom_scm_pas_auth_and_reset(BTSS_PAS_ID);
> + if (ret) {
> + dev_err(rproc->dev.parent, "Failed to start rproc: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int m0_btss_stop(struct rproc *rproc)
> +{
> + int ret;
> +
> + if (rproc->state == RPROC_RUNNING || rproc->state == RPROC_CRASHED) {
> + ret = qcom_scm_pas_shutdown(BTSS_PAS_ID);
> + if (ret) {
> + dev_err(rproc->dev.parent, "Failed to stop rproc: %d\n",
> + ret);
> + return ret;
> + }
> +
> + dev_info(rproc->dev.parent, "Successfully stopped rproc\n");
> + }
> +
> + return 0;
> +}
> +
> +static int m0_btss_load(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct m0_btss *desc = rproc->priv;
> + const struct elf32_phdr *phdrs;
> + const struct firmware *seg_fw;
> + const struct elf32_phdr *phdr;
> + const struct elf32_hdr *ehdr;
> + void __iomem *metadata;
> + size_t metadata_size;
> + int i, ret;
> +
> + ehdr = (const struct elf32_hdr *)fw->data;
> + phdrs = (const struct elf32_phdr *)(ehdr + 1);
> +
> + ret = request_firmware(&fw, rproc->firmware, rproc->dev.parent);
> + if (ret) {
> + dev_err(rproc->dev.parent, "Failed to request firmware: %d\n",
> + ret);
> + return ret;
> + }
> +
> + metadata = qcom_mdt_read_metadata(fw, &metadata_size, rproc->firmware,
> + rproc->dev.parent);
> + if (IS_ERR(metadata)) {
> + ret = PTR_ERR(metadata);
> + dev_err(rproc->dev.parent,
> + "Failed to read firmware metadata: %d\n", ret);
> + goto release_fw;
> + }
> +
> + ret = qcom_scm_pas_init_image(BTSS_PAS_ID, metadata,
> + metadata_size, NULL);
> + if (ret) {
> + dev_err(rproc->dev.parent, "PAS init image failed: %d\n", ret);
> + goto free_metadata;
> + }
> +
> + for (i = 0; i < ehdr->e_phnum; i++) {
> + char *seg_name __free(kfree) = kstrdup(rproc->firmware,
> + GFP_KERNEL);
> + if (!seg_name)
> + return -ENOMEM;
> +
> + phdr = &phdrs[i];
> +
> + /* Only process valid loadable data segments */
> + if (phdr->p_type != PT_LOAD || !phdr->p_memsz)
> + continue;
> +
> + if (phdr->p_vaddr + phdr->p_filesz > desc->mem_size) {
> + dev_err(rproc->dev.parent,
> + "Segment data exceeds the reserved memory area!\n");
> + goto free_metadata;
> + }
> +
> + /* Check if firmware is split across multiple segment files */
> + if (phdr->p_offset > fw->size ||
> + phdr->p_offset + phdr->p_filesz > fw->size) {
> + sprintf(seg_name + strlen(seg_name) - 3, "b%02d", i);
> + ret = request_firmware(&seg_fw, seg_name,
> + rproc->dev.parent);
> + if (ret) {
> + dev_err(rproc->dev.parent,
> + "Could not find split segment binary: %s\n",
> + seg_name);
> + goto free_metadata;
> + }
> +
> + /*
> + * Use the virtual instead of the physical address as
> + * the offset
> + */
> + memcpy_toio(desc->mem_region + phdr->p_vaddr,
> + seg_fw->data, phdr->p_filesz);
> +
> + release_firmware(seg_fw);
> + } else {
> + memcpy_toio(desc->mem_region + phdr->p_vaddr,
> + fw->data + phdr->p_offset, phdr->p_filesz);
> + }
> + }
> +
> + return 0;
> +
> +free_metadata:
> + kfree(metadata);
> +release_fw:
> + release_firmware(fw);
> + return ret;
> +}
> +
> +static const struct rproc_ops m0_btss_ops = {
> + .start = m0_btss_start,
> + .stop = m0_btss_stop,
> + .load = m0_btss_load,
> + .get_boot_addr = rproc_elf_get_boot_addr,
> +};
> +
> +static int m0_btss_alloc_memory_region(struct m0_btss *desc)
> +{
> + struct device *dev = desc->dev;
> + struct resource res;
> + int ret;
> +
> + ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
> + if (ret) {
> + dev_err(dev, "unable to acquire memory-region resource\n");
> + return ret;
> + }
> +
> + desc->mem_phys = res.start;
> + desc->mem_reloc = res.start;
> + desc->mem_size = resource_size(&res);
> + desc->mem_region = devm_ioremap(dev, desc->mem_phys, desc->mem_size);
> + if (!desc->mem_region) {
> + dev_err(dev, "unable to map memory region: %pR\n", &res);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static int m0_btss_pil_probe(struct platform_device *pdev)
> +{
> + // struct reset_control *btss_reset;
> + struct device *dev = &pdev->dev;
> + const char *fw_name = NULL;
> + struct m0_btss *desc;
> + struct clk *lpo_clk;
> + struct rproc *rproc;
> + int ret;
> +
> + ret = of_property_read_string(dev->of_node, "firmware-name",
> + &fw_name);
> + if (ret < 0)
> + return ret;
> +
> + rproc = devm_rproc_alloc(dev, "m0btss", &m0_btss_ops,
> + fw_name, sizeof(*desc));
> + if (!rproc) {
> + dev_err(dev, "failed to allocate rproc\n");
> + return -ENOMEM;
> + }
> +
> + desc = rproc->priv;
> + desc->dev = dev;
> +
> + ret = m0_btss_alloc_memory_region(desc);
> + if (ret)
> + return ret;
> +
> + lpo_clk = devm_clk_get_enabled(dev, "btss_lpo_clk");
> + if (IS_ERR(lpo_clk))
> + return dev_err_probe(dev, PTR_ERR(lpo_clk),
> + "Failed to get lpo clock\n");
> +
> + desc->btss_reset = devm_reset_control_get(dev, "btss_reset");
> + if (IS_ERR_OR_NULL(desc->btss_reset))
> + return dev_err_probe(dev, PTR_ERR(desc->btss_reset),
> + "unable to acquire btss_reset\n");
> +
> + ret = reset_control_deassert(desc->btss_reset);
> + if (ret)
> + return dev_err_probe(rproc->dev.parent, ret,
> + "Failed to deassert reset\n");
> +
> + rproc->auto_boot = false;
> + ret = devm_rproc_add(dev, rproc);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, rproc);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id m0_btss_of_match[] = {
> + { .compatible = "qcom,ipq5018-btss-pil" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, m0_btss_of_match);
> +
> +static struct platform_driver m0_btss_pil_driver = {
> + .probe = m0_btss_pil_probe,
> + .driver = {
> + .name = "qcom-m0-btss-pil",
> + .of_match_table = m0_btss_of_match,
> + },
> +};
> +
> +module_platform_driver(m0_btss_pil_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm M0 Bluetooth Subsystem Peripheral Image Loader");
> +MODULE_LICENSE("GPL");
>
> --
> 2.53.0
>
>
^ 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