* Re: [PATCH 1/3] wifi: mt76: connac: use a helper to cache txpower_cur
From: Lucid Duck @ 2026-03-27 2:15 UTC (permalink / raw)
To: sean.wang
Cc: nbd, lorenzo.bianconi, linux-wireless, linux-mediatek, morrownr,
satadru
In-Reply-To: <20260325043318.13298-1-sean.wang@kernel.org>
Adding Tested-by from Satadru Pramanik, who tested the full 3-patch
series on MT7925U with kernel 7.0-rc5 (US regdomain):
Before patch (5 GHz ch 36, 80 MHz): txpower 3.00 dBm
After patch (5 GHz ch 36, 80 MHz): txpower 23.00 dBm
Tested-by: Satadru Pramanik <satadru@gmail.com>
^ permalink raw reply
* Re: [GIT PULL] wireless-next-2026-03-26
From: patchwork-bot+netdevbpf @ 2026-03-27 1:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260326152021.305959-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 16:18:02 +0100 you wrote:
> Hi,
>
> So couple more things for now, including the NAN (Neighbor
> Awareness Networking) APIs that we spent a lot of time on
> trying to get right :) Other than that changes all over.
>
> We'll surely have more changes for NAN and also ranging
> (for proximity detection) is coming, it's looking to be
> a big 7.1 from a wifi perspective, but we'll see how it
> all comes together.
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-next-2026-03-26
https://git.kernel.org/netdev/net-next/c/dbd94b9831bc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH rtw-next] wifi: rtw89: Fill fw_version member of struct wiphy
From: kernel test robot @ 2026-03-27 1:19 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: oe-kbuild-all, Ping-Ke Shih
In-Reply-To: <60bdb2f8-d5dd-46a3-8679-5b4a5fd0604b@gmail.com>
Hi Bitterblue,
kernel test robot noticed the following build errors:
[auto build test ERROR on wireless-next/main]
[also build test ERROR on wireless/main linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Bitterblue-Smith/wifi-rtw89-Fill-fw_version-member-of-struct-wiphy/20260326-082721
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/60bdb2f8-d5dd-46a3-8679-5b4a5fd0604b%40gmail.com
patch subject: [PATCH rtw-next] wifi: rtw89: Fill fw_version member of struct wiphy
config: nios2-allmodconfig (https://download.01.org/0day-ci/archive/20260327/202603270937.xDZo9uy9-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260327/202603270937.xDZo9uy9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603270937.xDZo9uy9-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/net/wireless/realtek/rtw89/fw.c: In function 'rtw89_fw_update_ver':
>> drivers/net/wireless/realtek/rtw89/fw.c:759:21: error: 'RTW89_FW_NORMAL_B' undeclared (first use in this function); did you mean 'RTW89_FW_NORMAL_CE'?
759 | type == RTW89_FW_NORMAL_B)
| ^~~~~~~~~~~~~~~~~
| RTW89_FW_NORMAL_CE
drivers/net/wireless/realtek/rtw89/fw.c:759:21: note: each undeclared identifier is reported only once for each function it appears in
vim +759 drivers/net/wireless/realtek/rtw89/fw.c
726
727 static int rtw89_fw_update_ver(struct rtw89_dev *rtwdev,
728 enum rtw89_fw_type type,
729 struct rtw89_fw_suit *fw_suit)
730 {
731 const struct rtw89_fw_hdr *v0 = (const struct rtw89_fw_hdr *)fw_suit->data;
732 const struct rtw89_fw_hdr_v1 *v1 = (const struct rtw89_fw_hdr_v1 *)fw_suit->data;
733
734 if (type == RTW89_FW_LOGFMT)
735 return 0;
736
737 fw_suit->type = type;
738 fw_suit->hdr_ver = le32_get_bits(v0->w3, FW_HDR_W3_HDR_VER);
739
740 switch (fw_suit->hdr_ver) {
741 case 0:
742 rtw89_fw_update_ver_v0(rtwdev, fw_suit, v0);
743 break;
744 case 1:
745 rtw89_fw_update_ver_v1(rtwdev, fw_suit, v1);
746 break;
747 default:
748 rtw89_err(rtwdev, "Unknown firmware header version %u\n",
749 fw_suit->hdr_ver);
750 return -ENOENT;
751 }
752
753 rtw89_info(rtwdev,
754 "Firmware version %u.%u.%u.%u (%08x), cmd version %u, type %u\n",
755 fw_suit->major_ver, fw_suit->minor_ver, fw_suit->sub_ver,
756 fw_suit->sub_idex, fw_suit->commitid, fw_suit->cmd_ver, type);
757
758 if (type == RTW89_FW_NORMAL || type == RTW89_FW_NORMAL_CE ||
> 759 type == RTW89_FW_NORMAL_B)
760 snprintf(rtwdev->hw->wiphy->fw_version,
761 sizeof(rtwdev->hw->wiphy->fw_version),
762 "%u.%u.%u.%u",
763 fw_suit->major_ver, fw_suit->minor_ver,
764 fw_suit->sub_ver, fw_suit->sub_idex);
765
766 return 0;
767 }
768
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-03-26
From: patchwork-bot+netdevbpf @ 2026-03-27 1:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260326093329.77815-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 10:31:35 +0100 you wrote:
> Hi,
>
> And ... more fixes from drivers came in, notably iwlwifi with
> a bunch of things (their maintainer had been on vacation).
>
> I'm going to be on vacation next week, but I'm also not aware
> of anything missing from drivers etc. right now, so we'll see.
> I doubt this is the _last_ pull request for 7.0, but I think
> not much more will come in.
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-2026-03-26
https://git.kernel.org/netdev/net/c/45dbf8fcea4d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH rtw-next v2] wifi: rtw88: Fill fw_version member of struct wiphy
From: Jeff Johnson @ 2026-03-27 0:26 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org; +Cc: Ping-Ke Shih
In-Reply-To: <3701cce1-42c4-4382-9120-cd21012c1b21@gmail.com>
On 3/26/2026 8:21 AM, Bitterblue Smith wrote:
> Let userspace tools like lshw show the firmware version by filling the
> fw_version member of struct wiphy.
>
> Before:
>
> configuration: broadcast=yes driver=rtw88_8814au
> driverversion=6.19.6-arch1-1 firmware=N/A link=no multicast=yes
> wireless=IEEE 802.11
>
> After:
>
> configuration: broadcast=yes driver=rtw88_8814au
> driverversion=6.19.6-arch1-1 firmware=33.6.0 link=no multicast=yes
> wireless=IEEE 802.11
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> ---
> v2:
> - Use local wiphy variable.
> ---
> drivers/net/wireless/realtek/rtw88/main.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index c4f9758b4e96..cd9254370fcc 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1805,6 +1805,7 @@ static void rtw_load_firmware_cb(const struct firmware *firmware, void *context)
> {
> struct rtw_fw_state *fw = context;
> struct rtw_dev *rtwdev = fw->rtwdev;
> + struct wiphy *wiphy = rtwdev->hw->wiphy;
>
> if (!firmware || !firmware->data) {
> rtw_err(rtwdev, "failed to request firmware\n");
> @@ -1819,6 +1820,11 @@ static void rtw_load_firmware_cb(const struct firmware *firmware, void *context)
> rtw_info(rtwdev, "%sFirmware version %u.%u.%u, H2C version %u\n",
> fw->type == RTW_WOWLAN_FW ? "WOW " : "",
> fw->version, fw->sub_version, fw->sub_index, fw->h2c_version);
> +
> + if (fw->type == RTW_NORMAL_FW)
> + snprintf(wiphy->fw_version, sizeof(wiphy->fw_version),
> + "%u.%u.%u",
> + fw->version, fw->sub_version, fw->sub_index);
> }
>
> static int rtw_load_firmware(struct rtw_dev *rtwdev, enum rtw_fw_type type)
generically speaking how useful is this?
with MLO and multi-radio wiphy there can be multiple underlying hardware with
different firmware versions. in recent ath drivers we are not filling this.
/jeff
^ permalink raw reply
* Re: [PATCH 1/3] wifi: mt76: connac: use a helper to cache txpower_cur
From: Sean Wang @ 2026-03-27 0:23 UTC (permalink / raw)
To: Lucid Duck
Cc: nbd, lorenzo.bianconi, linux-wireless, linux-mediatek, morrownr
In-Reply-To: <20260326170407.406431-1-lucid_duck@justthetip.ca>
Hi, Lucid
On Thu, Mar 26, 2026 at 12:04 PM Lucid Duck <lucid_duck@justthetip.ca> wrote:
>
> Sean,
>
> Tested the full 3-patch series on MT7921AU. All three bands working
> correctly -- txpower reporting is fixed.
>
> Test environment:
>
> Kernel: 6.19.8-200.fc43.x86_64 (Fedora 43)
> Device: MediaTek MT7921AU USB (0e8d:7961)
> Firmware: HW/SW 0x8a108a10, WM 20251223091148
> AP: Tri-band (2.4/5/6 GHz)
> Regdomain: CA (DFS-FCC), also tested US, JP, DE
> Note: Internet maintained via separate USB ethernet
> adapter during WiFi testing
>
> Baseline (stock 6.19.8, pre-patch):
>
> txpower 3.00 dBm on all bands
>
> Post-patch txpower:
>
> 2.4 GHz ch 1 (2412 MHz, 20 MHz): 36.00 dBm
> 5 GHz ch 100 (5500 MHz, 80 MHz): 26.00 dBm
> 6 GHz ch 5 (5975 MHz, 80 MHz): 12.00 dBm
>
> All values match expected CA regulatory limits. Connectivity verified
> with 0% packet loss on every band.
>
> Stress testing (28 tests, 28 passed, 0 failed):
>
> - Connect/disconnect: 10 cycles per band (30 total), txpower
> correct and ping 0% loss on every cycle
> - Band switching: 30 sequential hops (2.4 -> 5 -> 6 -> repeat),
> txpower correct on every hop, ping 30/30
> - Module reload: 15 full rmmod/insmod cycles of all mt76 modules,
> txpower correct after every reload
> - Throughput: 100-ping per band, 0% loss on all
> 2.4 GHz: avg 2.4 ms, max 23.6 ms
> 5 GHz: avg 1.9 ms, max 8.0 ms
> 6 GHz: avg 2.2 ms, max 3.3 ms
> - Soak: 20-minute continuous test per band (60 min total),
> txpower sampled every 30 seconds, never deviated
> 2.4 GHz: 40/40 samples at 36.00 dBm, slab delta -4 kB
> 5 GHz: 40/40 samples at 26.00 dBm, slab delta +16 kB
> 6 GHz: 40/40 samples at 12.00 dBm, slab delta -16 kB
> - Memory: 50 connect/disconnect cycles, slab delta +64 kB
> (negligible, no leak)
> - Band-hop marathon: 200 random band hops, 200/200 pass,
> ping 200/200 OK, completed in 1232 seconds
> - Concurrent managed + monitor: txpower stable on all bands
> with a monitor VIF present, ping 0% loss
> - Regulatory domain switching: txpower correctly adjusts
> per country on 5 GHz
> CA: 26.00 dBm
> US: 24.00 dBm
> JP: 23.00 dBm
> DE: 26.00 dBm
>
> Zero kernel warnings in dmesg throughout all testing.
>
> For context, I originally reported this bug and submitted a fix in
> January (v1 through v4 on linux-wireless, as Lucid Duck). Patches 1
> and 2 in this series address the same core issue -- capturing the rate
> power loop output and subtracting the path delta before caching
> txpower_cur. Patch 3 (the per-vif-link get_txpower callback) is a
> good addition that was not in my series.
Thanks a lot for the detailed testing and for confirming the fix on MT7921AU.
This was my mistake. Patches 1 and 2 do overlap with the core fix
direction from your January series, and I should have credited that
more clearly.
I’ll add a Co-developed-by tag for you in patches 1 and 2, along with
proper attribution in the next revision.
Sean
>
> Reported-by: Lucid Duck <lucid_duck@justthetip.ca>
> Tested-by: Lucid Duck <lucid_duck@justthetip.ca>
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-03-26 23:52 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqQ5U2USCqVEixoDda1Xd2ugBakh1K1QkaKAU7HPSTTNWg@mail.gmail.com>
Hi Ping-Ke,
This is Oleksandr Havrylov again. Thank you for the ASPM/LPS Deep
quirk and the rate validation patches — they are both working correctly
(zero h2c timeouts, zero lps failures, zero mac80211 warnings).
However, I'm experiencing a different, separate bug that causes kernel
oops and makes the system completely unresponsive, requiring a hard
power-off. After disassembling the crash site, I believe I've found
the root cause.
== Summary ==
When firmware sends a C2H_ADAPTIVITY (0x37) command to an RTL8821CE
adapter, rtw_fw_adaptivity_result() dereferences rtwdev->chip->edcca_th
without a NULL check. The RTL8821C chip_info (rtw8821c_hw_spec) does
not define edcca_th, so the pointer is NULL, causing a kernel oops.
The crash occurs on the phy0 workqueue while holding rtwdev->mutex,
which never gets released. This causes all subsequent processes that
touch the network stack to hang in uninterruptible D-state, making
the system completely unresponsive and requiring a hard power-off.
== Root cause analysis ==
rtw_fw_adaptivity_result() in fw.c (line ~282):
static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
u8 length)
{
const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
...
rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
^^^^^^^^^ NULL dereference here
edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
...
The RTL8822C defines .edcca_th = rtw8822c_edcca_th in its chip_info,
but RTL8821C does not set this field at all — it remains NULL.
I verified this by disassembling the compiled rtw_core.ko module:
Crash RIP: rtw_fw_c2h_cmd_handle+0x127
Address: 0x1d527 = movl (%r12), %esi
R12 is loaded at +0xe5 (0x1d4e5):
movq 0x140(%rax), %r12 ; rax = rtwdev->chip
; 0x140 = offset of edcca_th in rtw_chip_info
; R12 = chip->edcca_th = NULL for 8821c
The function is entered via:
+0xd8 (0x1d4d8): cmpl $0x37, %ecx ; c2h->id == C2H_ADAPTIVITY (0x37)
With R12 = 0, the instruction at +0x127:
movl (%r12), %esi ; reads from address 0x0 → NULL pointer dereference
I also confirmed that rtw8821c_hw_spec in the mainline kernel
(torvalds/linux master, rtw8821c.c) does NOT set .edcca_th.
== Reproduction ==
The crash is highly reproducible: it occurred in 4 out of 7 recent
boots. It happens during normal active usage with no specific trigger.
boot date/time of crash uptime at crash
-5 2026-03-25 00:58:06 ~2 min
-4 2026-03-25 21:32:00 ~6h
-3 2026-03-26 00:28:14 ~2.5h
-1 2026-03-27 00:56:58 ~23.5h
Both ASPM and LPS Deep are disabled via the DMI quirk. The crash
occurs every time with the same pattern and same RIP offset (+0x127).
== Crash pattern ==
Every crash follows the same sequence:
1) Burst of 50-60 "unused phy status page" messages in ~1 second:
rtw_8821ce 0000:13:00.0: unused phy status page (8)
rtw_8821ce 0000:13:00.0: unused phy status page (2)
... (50+ more within same second)
2) Immediately followed by the kernel oops:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: 0000 [#1] SMP PTI
Workqueue: phy0 rtw_c2h_work [rtw_core]
RIP: 0010:rtw_fw_c2h_cmd_handle+0x127/0x380 [rtw_core]
CR2: 0000000000000000
R12: 0000000000000000 ← edcca_th = NULL
Call Trace:
<TASK>
rtw_c2h_work+0x49/0x70 [rtw_core]
process_scheduled_works+0x1f3/0x5e0
worker_thread+0x18d/0x340
</TASK>
note: kworker/u16:6[262] exited with irqs disabled
3) After the oops, processes hang in D-state indefinitely:
warp-svc, avahi-daemon, kdeconnectd — all survive SIGKILL,
making clean shutdown impossible.
== Suggested fix ==
Add a NULL check for edcca_th in rtw_fw_adaptivity_result():
static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
u8 length)
{
const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
struct rtw_c2h_adaptivity *result = (struct rtw_c2h_adaptivity *)payload;
+ if (!edcca_th)
+ return;
+
rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY,
...
Alternatively, the C2H_ADAPTIVITY case in rtw_fw_c2h_cmd_handle()
could check edcca_th before calling the handler. However, since
RTL8821CE firmware does occasionally send C2H_ADAPTIVITY commands
(as observed in this bug), you may have a better understanding of
whether a more complete fix is needed (e.g., defining edcca_th for
RTL8821C, or preventing the firmware from sending C2H_ADAPTIVITY
responses when the feature is not fully configured).
== Hardware ==
Machine: HP HP Notebook (board: 81F0, SKU: P3S95EA#ACB)
Adapter: RTL8821CE (PCI 10ec:c821, bus 0000:13:00.0)
CPU: Intel 5005U
Kernel: 6.19.9-2-cachyos (PREEMPT full, SMP PTI, LLVM build)
Driver: lwfinger/rtw88 out-of-tree with DMI quirk + rate v2
== Confirmation that this is NOT a local modification ==
I verified that:
- fw.c: rtw_fw_c2h_cmd_handle() and rtw_fw_adaptivity_result() are
byte-for-byte identical to torvalds/linux master and lwfinger/rtw88
- rtw8821c.c: rtw8821c_hw_spec does not define .edcca_th in any of
the three sources (mainline, lwfinger, our local copy)
- The only local modifications are your DMI quirk (pci.c + main.h)
and rate validation v2 (rx.c). Neither touches fw.c.
Please let me know if you need additional diagnostics or if you'd
like me to test a patch.
Best regards,
Oleksandr Havrylov <goainwo@gmail.com>
Tested on:
Kernel: 6.19.9-2-cachyos
Driver: lwfinger/rtw88 out-of-tree with DMI quirk + rate v2 patch
Distro: CachyOS (Arch-based)
ср, 25 мар. 2026 г. в 22:38, LB F <goainwo@gmail.com>:
>
> Subject: Cross-platform analysis: RTL8821CE ASPM/LPS instability
> affects multiple OEM platforms beyond HP P3S95EA#ACB
>
> Hi Ping-Ke,
>
> First of all, thank you very much for your work on the rtw88 driver
> and for the time you spent helping us resolve the issues on our HP
> laptop. Both patches -- the v2 DMI quirk (ASPM + LPS Deep) and the
> v2 RX rate validation (rx.c) -- have been tested and verified stable
> on our system across two kernel updates (6.19.9-1 and 6.19.9-2),
> sustained network load (~1.9 GB), and multiple suspend/resume cycles.
> The system is now completely free of freezes, h2c errors, and
> mac80211 warnings. Your patches genuinely solved every issue we had.
>
> While working through this, I noticed that many other users across
> different hardware platforms appear to be experiencing the same
> problems that your patches resolved for us. I decided to collect
> and organize these observations in case they might be useful to you.
>
> Please note that this is an amateur analysis, not a professional
> one -- I am just a user trying to help. It is entirely possible
> that I have missed nuances or made incorrect assumptions. My only
> goal is to share what I found, in case it provides useful data
> points or sparks ideas for broader improvements. If any of this
> is not relevant or not useful, please feel free to disregard it.
>
>
> 1. KERNEL BUGZILLA: OPEN RTL8821CE REPORTS
> ==========================================
>
> I reviewed all open RTL8821CE bugs in kernel.org Bugzilla. Three
> of the six show symptoms that directly match the root causes
> addressed by your patches (ASPM deadlock and LPS Deep h2c failures).
>
> --- Directly correlated with ASPM/LPS patches ---
>
> Bug 215131 - System freeze (ASPM L1 deadlock)
> Title: "Realtek 8821CE makes the system freeze after 9e2fd29864c5
> (rtw88: add napi support)"
> Reporter: Kai-Heng Feng (Canonical)
> Kernel: 5.15+
> Symptoms: Hard freeze preceded by "pci bus timeout, check dma status"
> warnings. RX tag mismatch in rtw_pci_dma_check().
> Workaround confirmed by reporter: rtw88_pci.disable_aspm=1
> Reporter note: "disable_aspm=1 is not a viable workaround because
> it increases power consumption significantly"
> Status: OPEN since 2021-11-24.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215131
> Relevance: Identical root cause to Bug 221195. The reporter's
> confirmed workaround (disable_aspm=1) is exactly what
> the DMI quirk implements.
>
> Bug 219830 - h2c/LPS failures + BT crackling
> Title: "rtw88_8821ce (RTL8821CE) slow performance and error
> messages in dmesg"
> Reporter: Bmax Y14 laptop, Fedora 41, kernel 6.13.5
> Symptoms: - "failed to send h2c command" (periodic)
> - "firmware failed to leave lps state" (periodic)
> - Lower signal strength vs Windows
> - Bluetooth crackling during audio playback
> Cross-ref: https://github.com/lwfinger/rtw88/issues/306
> Status: OPEN since 2025-03-02.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219830
> Relevance: The h2c/lps errors are the same messages we observed
> before the DMI quirk disabled LPS Deep Mode. The BT
> crackling may correlate with the invalid RX rate
> condition addressed by your rx.c validation patch.
>
> Bug 218697 - TX queue flush timeout during scan
> Title: "rtw88_8821ce timed out to flush queue 2"
> Reporter: Arch Linux, kernel 6.8.4 / 6.8.5
> Symptoms: - "timed out to flush queue 2" every ~30 seconds
> - "failed to get tx report from firmware"
> - Stack trace: ieee80211_scan_work -> rtw_ops_flush ->
> rtw_mac_flush_queues timeout
> Status: OPEN since 2024-04-08.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218697
> Relevance: The flush timeout occurs when the firmware cannot
> respond to TX queue operations -- consistent with
> firmware being stuck in LPS Deep during scan.
>
> --- Potentially related (no confirmed workaround data) ---
>
> Bug 217491 - "timed out to flush queue 1" regression (kernel 6.3)
> Manjaro user. Floods of "timed out to flush queue 1/2".
> Similar pattern to Bug 218697.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217491
>
> Bug 217781 - Random sudden dropouts
> Arch user. Random disconnections during streaming/transfers.
> Reproduced on Ubuntu and Fedora (kernels 5.15 to 6.4).
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217781
>
> Bug 216685 - Low wireless speed
> Reduced throughput vs expected 802.11ac performance.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216685
>
>
> 2. SYMPTOM-TO-PATCH MAPPING
> =============================
>
> dmesg signature Patch that resolves it
> -------------------------- ----------------------
> Hard system freeze pci.c DMI quirk (disable ASPM)
> "pci bus timeout, check dma" pci.c DMI quirk (disable ASPM)
> "firmware failed to leave lps" pci.c DMI quirk (disable LPS Deep)
> "failed to send h2c command" pci.c DMI quirk (disable LPS Deep)
> "timed out to flush queue N" pci.c DMI quirk (disable LPS Deep) [1]
> "failed to get tx report" pci.c DMI quirk (disable LPS Deep) [1]
> VHT NSS=0 mac80211 WARNING rx.c rate validation (v2)
>
> Confirmed in bugs: 215131, 219830, 218697, 221195.
> [1] Inferred: flush timeout occurs when firmware cannot exit LPS
> to process TX queue operations.
>
>
> 3. AFFECTED HARDWARE
> =====================
>
> Current DMI quirk coverage: HP P3S95EA#ACB only.
>
> Platforms confirmed affected in Bugzilla:
> Bug 221195: HP Notebook 81F0 (P3S95EA#ACB)
> Bug 215131: unknown (Canonical upstream testing)
> Bug 219830: Bmax Y14
> Bug 218697: unknown (Arch Linux user)
>
> Platforms reported in community forums as requiring
> disable_aspm=Y and/or disable_lps_deep=Y for stable RTL8821CE:
> - HP 17-by4063CL
> - Lenovo IdeaPad S145-15AST, IdeaPad 3, IdeaPad 330S
> - ASUS VivoBook X series
> - Acer Aspire 3/5 series
>
> All use PCI Device ID 10ec:c821 with different Subsystem IDs.
>
>
> 4. LPS_DEEP_MODE_LCLK IN THE rtw88 TREE
> =========================================
>
> I verified in the source which chips have the same
> lps_deep_mode_supported flag:
>
> Chip file lps_deep_mode_supported PCIe variant
> --------- ----------------------- ------------
> rtw8821c.c BIT(LPS_DEEP_MODE_LCLK) rtw8821ce ✓
> rtw8822c.c BIT(LPS_DEEP_MODE_LCLK) | PG rtw8822ce ✓
> rtw8822b.c BIT(LPS_DEEP_MODE_LCLK) rtw8822be ✓
> rtw8814a.c BIT(LPS_DEEP_MODE_LCLK) rtw8814ae ✓
> rtw8723d.c 0 rtw8723de ✗
> rtw8703b.c 0 (SDIO) -
> rtw8821a.c 0 (legacy) -
>
> Source references:
> rtw8821c.c:2002 rtw8822c.c:5365 rtw8822b.c:2545
> rtw8814a.c:2211 rtw8723d.c:2144
>
> RTL8822CE community reports (Manjaro, Arch forums) confirm the
> same disable_aspm=Y + disable_lps_deep=Y workaround is effective,
> consistent with rtw8822c.c having LCLK enabled.
>
>
> 5. COMMUNITY WORKAROUND REFERENCES
> ====================================
>
> The following are concrete examples of forums and wikis where the
> same modprobe workarounds are actively recommended:
>
> Arch Wiki - RTW88 section:
> https://wiki.archlinux.org/title/Network_configuration/Wireless
> (section "RTW88" and "rtl8821ce" under Troubleshooting/Realtek)
> Recommends rtw88-dkms-git and documents the rtw88_8821ce issues.
>
> Arch Wiki - RTW89 section (same page):
> Documents the identical ASPM pattern for the newer RTW89 driver:
> options rtw89_pci disable_aspm_l1=y disable_aspm_l1ss=y
> options rtw89_core disable_ps_mode=y
> This suggests the ASPM/LPS interaction is a systemic Realtek
> design issue, not specific to rtw88 or the 8821CE chip.
>
> Arch Linux Forum - RTL8821CE thread:
> https://bbs.archlinux.org/viewtopic.php?id=273440
> Referenced by the Arch Wiki as the primary rtl8821ce discussion.
>
> lwfinger/rtw88 GitHub:
> https://github.com/lwfinger/rtw88/issues/306
> Directly cross-referenced by Bug 219830. Reporter reports h2c
> errors and investigated antenna hardware (no fault found).
>
> lwfinger/rtw89 GitHub:
> https://github.com/lwfinger/rtw89/issues/275#issuecomment-1784155449
> Same ASPM-disable pattern documented for the newer RTW89 driver
> on HP and Lenovo laptops.
>
>
> 6. OBSERVATIONS
> ================
>
> a) Three open Bugzilla reporters (215131, 219830, 218697) show
> symptoms identical to those resolved by your patches but have
> no upstream fix available since they are not the HP P3S95EA#ACB.
>
> b) Bug 215131 reporter (Kai-Heng Feng, Canonical) explicitly
> confirmed disable_aspm=1 as a workaround and called it
> "not viable" due to power cost. A DMI quirk for their
> platform would give them a proper fix.
>
> c) The Arch Wiki documents the same ASPM-disable pattern for
> both RTW88 and RTW89 drivers, suggesting the underlying
> hardware/firmware limitation is shared across generations.
>
> d) Asking Bugzilla reporters to provide their DMI data
> (dmidecode -t 1,2) could allow extending the quirk table
> with minimal effort and zero risk to unaffected platforms.
>
> e) The rx.c rate validation patch is chip-agnostic and requires
> no platform-specific consideration.
>
>
> 7. REFERENCES
> ==============
>
> Kernel Bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=215131
> https://bugzilla.kernel.org/show_bug.cgi?id=219830
> https://bugzilla.kernel.org/show_bug.cgi?id=218697
> https://bugzilla.kernel.org/show_bug.cgi?id=217491
> https://bugzilla.kernel.org/show_bug.cgi?id=217781
> https://bugzilla.kernel.org/show_bug.cgi?id=216685
>
> GitHub:
> https://github.com/lwfinger/rtw88/issues/306
> https://github.com/lwfinger/rtw89/issues/275
>
> Arch Wiki:
> https://wiki.archlinux.org/title/Network_configuration/Wireless
>
> Arch Linux Forum:
> https://bbs.archlinux.org/viewtopic.php?id=273440
>
> Source code (lps_deep_mode_supported):
> drivers/net/wireless/realtek/rtw88/rtw8821c.c:2002
> drivers/net/wireless/realtek/rtw88/rtw8822c.c:5365
> drivers/net/wireless/realtek/rtw88/rtw8822b.c:2545
> drivers/net/wireless/realtek/rtw88/rtw8814a.c:2211
> drivers/net/wireless/realtek/rtw88/rtw8723d.c:2144
>
>
> Best regards,
> Oleksandr Havrylov <goainwo@gmail.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath10k: fix station lookup failure during disconnect
From: Paul Menzel @ 2026-03-26 23:31 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson; +Cc: linux-wireless, ath10k
In-Reply-To: <20260325-ath10k-station-lookup-failure-v1-1-2e0c970f25d5@oss.qualcomm.com>
Dear Baochen,
Thank you for sending the patch out.
Am 25.03.26 um 04:05 schrieb Baochen Qiang:
> Recent commit [1] moved station statistics collection to an earlier stage
> of the disconnect flow. With this change in place, ath10k fails to resolve
> the station entry when handling a peer stats event triggered during
> disconnect, resulting in log messages such as:
>
> wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING)
> ath10k_pci 0000:3a:00.0: not found station for peer stats
> ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22
>
> The failure occurs because ath10k relies on ieee80211_find_sta_by_ifaddr()
> for station lookup. That function uses local->sta_hash, but by the time
> the peer stats request is triggered during disconnect, mac80211 has
> already removed the station from that hash table, leading to lookup
> failure.
>
> Before commit [1], this issue was not visible because the transition from
> IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST prevented ath10k from sending
> a peer stats request at all: ath10k_mac_sta_get_peer_stats_info() would
> fail early to find the peer and skip requesting statistics.
>
> Fix this by switching the lookup path to ath10k_peer_find(), which queries
> ath10k's internal peer table. At the point where the firmware emits the
> peer stats event, the peer entry is still present in the driver's list,
> ensuring lookup succeeds.
Out of curiosity, how can the statistics be printed?
> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1
>
> Fixes: a203dbeeca15 ("wifi: mac80211: collect station statistics earlier when disconnect") # [1]
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Closes: https://lore.kernel.org/ath10k/57671b89-ec9f-4e6c-992c-45eb8e75929c@molgen.mpg.de
> Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/wmi-tlv.c | 26 +++++++++++++++-----------
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> index ec8e91707f84..01f2d1fa9d7d 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
> @@ -3,7 +3,7 @@
> * Copyright (c) 2005-2011 Atheros Communications Inc.
> * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
> * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
> - * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
> #include "core.h"
> #include "debug.h"
> @@ -14,6 +14,7 @@
> #include "wmi-tlv.h"
> #include "p2p.h"
> #include "testmode.h"
> +#include "txrx.h"
> #include <linux/bitfield.h>
>
> /***************/
> @@ -224,8 +225,9 @@ static int ath10k_wmi_tlv_parse_peer_stats_info(struct ath10k *ar, u16 tag, u16
> const void *ptr, void *data)
> {
> const struct wmi_tlv_peer_stats_info *stat = ptr;
> - struct ieee80211_sta *sta;
> + u32 vdev_id = *(u32 *)data;
> struct ath10k_sta *arsta;
> + struct ath10k_peer *peer;
>
> if (tag != WMI_TLV_TAG_STRUCT_PEER_STATS_INFO)
> return -EPROTO;
> @@ -241,20 +243,20 @@ static int ath10k_wmi_tlv_parse_peer_stats_info(struct ath10k *ar, u16 tag, u16
> __le32_to_cpu(stat->last_tx_rate_code),
> __le32_to_cpu(stat->last_tx_bitrate_kbps));
>
> - rcu_read_lock();
> - sta = ieee80211_find_sta_by_ifaddr(ar->hw, stat->peer_macaddr.addr, NULL);
> - if (!sta) {
> - rcu_read_unlock();
> - ath10k_warn(ar, "not found station for peer stats\n");
> + guard(spinlock_bh)(&ar->data_lock);
> +
> + peer = ath10k_peer_find(ar, vdev_id, stat->peer_macaddr.addr);
> + if (!peer || !peer->sta) {
> + ath10k_warn(ar, "not found %s with vdev id %u mac addr %pM for peer stats\n",
> + peer ? "sta" : "peer", vdev_id, stat->peer_macaddr.addr);
> return -EINVAL;
> }
>
> - arsta = (struct ath10k_sta *)sta->drv_priv;
> + arsta = (struct ath10k_sta *)peer->sta->drv_priv;
> arsta->rx_rate_code = __le32_to_cpu(stat->last_rx_rate_code);
> arsta->rx_bitrate_kbps = __le32_to_cpu(stat->last_rx_bitrate_kbps);
> arsta->tx_rate_code = __le32_to_cpu(stat->last_tx_rate_code);
> arsta->tx_bitrate_kbps = __le32_to_cpu(stat->last_tx_bitrate_kbps);
> - rcu_read_unlock();
>
> return 0;
> }
> @@ -266,6 +268,7 @@ static int ath10k_wmi_tlv_op_pull_peer_stats_info(struct ath10k *ar,
> const struct wmi_tlv_peer_stats_info_ev *ev;
> const void *data;
> u32 num_peer_stats;
> + u32 vdev_id;
> int ret;
>
> tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
> @@ -284,15 +287,16 @@ static int ath10k_wmi_tlv_op_pull_peer_stats_info(struct ath10k *ar,
> }
>
> num_peer_stats = __le32_to_cpu(ev->num_peers);
> + vdev_id = __le32_to_cpu(ev->vdev_id);
>
> ath10k_dbg(ar, ATH10K_DBG_WMI,
> "wmi tlv peer stats info update peer vdev id %d peers %i more data %d\n",
> - __le32_to_cpu(ev->vdev_id),
> + vdev_id,
> num_peer_stats,
> __le32_to_cpu(ev->more_data));
>
> ret = ath10k_wmi_tlv_iter(ar, data, ath10k_wmi_tlv_len(data),
> - ath10k_wmi_tlv_parse_peer_stats_info, NULL);
> + ath10k_wmi_tlv_parse_peer_stats_info, &vdev_id);
> if (ret)
> ath10k_warn(ar, "failed to parse stats info tlv: %d\n", ret);
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH v3 00/13] This series adds support for the MediaTek MT7927 (Filogic 380) combo
From: Javier Tia @ 2026-03-26 21:09 UTC (permalink / raw)
To: Sean Wang
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
Hi Sean,
On Wed, Mar 26, 2026 Sean Wang wrote:
> This part patch 1-8 looks good overall. My only concern was a possible
> regression on mt7925, but now that the incorrect mt7925 320 MHz
> support has been fixed in the version, this should be fine.
Thank you. Patch 5 also had a build error (is_320mhz_supported()
called is_mt7927() before it was defined in patch 6). Fixed in v4
by using mt76_chip() directly.
> I am still thinking a bit more about patches 9-11. My current
> preference is to introduce the generic layer first, and then migrate
> the mt7925 and mt7927-specific parts on top of it.
> I will handle this part on my side, since I want to carefully compare
> the vendor driver with your changes first, and make sure the mt7925
> side is solid before moving the mt7927-related changes forward. For
> the mt7927-related work, I will make sure your contribution, as well
> as the work from the other volunteers, is properly preserved when I
> carry this forward.
Understood. v4 drops patches 9-13 so you have full control over
the DMA, HW init, band_idx, and PCI device ID enablement.
Regarding your feedback on v3 patch 13 (CNM quirk) - you suggested
folding the MT792x_FW_CAP_CNM force into mt792x_get_mac80211_ops()
instead of the post-hoc memcpy. Since the PCI IDs patch is now
part of your series, would you prefer to handle the CNM fix there
as well, or should I send a standalone patch for it ahead of your
DMA/init work?
> Similar to the BT side, I would prefer to have a dedicated Linux
> firmware for mt7927 WiFi.
Noted. The driver currently requests mediatek/mt7927/ paths. Once
a dedicated firmware is available we can adjust if needed.
v4 sent with patches 1-8 + ASPM/PM disable (9 patches):
https://lore.kernel.org/linux-wireless/20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me/T/#u
Best,
Javier
^ permalink raw reply
* [PATCH v4 9/9] wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power
domain and WFDMA register access are unreliable with PCIe L1 active,
causing throughput to drop from 1+ Gbps to ~200 Mbps.
Disable runtime PM and deep sleep for MT7927. The combo chip shares
a CONNINFRA power domain between WiFi (PCIe) and BT (USB).
SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
firmware, requiring a full power cycle to recover. PM enablement will
be addressed in a follow-up once safe power state transitions are
determined.
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/init.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 6 ++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/init.c b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
index 3ce5d6fcc69d..4766b9343953 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/init.c
@@ -230,7 +230,8 @@ int mt7925_register_device(struct mt792x_dev *dev)
dev->pm.idle_timeout = MT792x_PM_TIMEOUT;
dev->pm.stats.last_wake_event = jiffies;
dev->pm.stats.last_doze_event = jiffies;
- if (!mt76_is_usb(&dev->mt76)) {
+ /* MT7927: runtime PM crashes BT firmware on the shared CONNINFRA domain */
+ if (!mt76_is_usb(&dev->mt76) && !is_mt7927(&dev->mt76)) {
dev->pm.enable_user = true;
dev->pm.enable = true;
dev->pm.ds_enable_user = true;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index 604c0e9ae7ba..1f05c212be02 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -350,7 +350,10 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_free_pci_vec;
- if (mt7925_disable_aspm)
+ is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
+
+ /* MT7927: ASPM L1 causes unreliable WFDMA register access */
+ if (mt7925_disable_aspm || is_mt7927_hw)
mt76_pci_disable_aspm(pdev);
ops = mt792x_get_mac80211_ops(&pdev->dev, &mt7925_ops,
@@ -371,7 +374,6 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &mt7925_pcie_ops;
- is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
dev->irq_map = is_mt7927_hw ? &mt7927_irq_map : &irq_map;
mt76_mmio_init(&dev->mt76, pcim_iomap_table(pdev)[0]);
tasklet_init(&mdev->irq_tasklet, mt792x_irq_tasklet, (unsigned long)dev);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 8/9] wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The mac_reset and resume paths use the hardcoded MT_INT_RX_DONE_ALL
constant (bits 0-2) to re-enable RX interrupts. This is correct for
MT7925 (RX rings 0, 1, 2) but wrong for chips using different ring
indices.
Define a per-chip irq_map with the correct RX interrupt enable bits and
replace hardcoded MT_INT_RX_DONE_ALL with irq_map field reads in the
resume and mac_reset paths. Add the MT7927 irq_map with interrupt bits
matching its RX ring layout (rings 4, 6, 7), selected at probe time
based on PCI device ID.
This ensures the correct interrupt bits are enabled regardless of the
chip variant.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 21 +++++++++++++++++++--
drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c | 5 ++++-
drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 3 +++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index f820d5aeb723..604c0e9ae7ba 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -266,6 +266,18 @@ static int mt7925_dma_init(struct mt792x_dev *dev)
return mt792x_dma_enable(dev);
}
+static const struct mt792x_irq_map mt7927_irq_map = {
+ .host_irq_enable = MT_WFDMA0_HOST_INT_ENA,
+ .tx = {
+ .all_complete_mask = MT_INT_TX_DONE_ALL,
+ .mcu_complete_mask = MT_INT_TX_DONE_MCU,
+ },
+ .rx = {
+ .data_complete_mask = MT7927_RX_DONE_INT_ENA4,
+ .wm_complete_mask = MT7927_RX_DONE_INT_ENA6,
+ .wm2_complete_mask = MT7927_RX_DONE_INT_ENA7,
+ },
+};
static int mt7925_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
@@ -310,6 +322,7 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
struct mt76_bus_ops *bus_ops;
struct mt792x_dev *dev;
struct mt76_dev *mdev;
+ bool is_mt7927_hw;
u8 features;
int ret;
u16 cmd;
@@ -358,7 +371,8 @@ static int mt7925_pci_probe(struct pci_dev *pdev,
dev = container_of(mdev, struct mt792x_dev, mt76);
dev->fw_features = features;
dev->hif_ops = &mt7925_pcie_ops;
- dev->irq_map = &irq_map;
+ is_mt7927_hw = (pdev->device == 0x6639 || pdev->device == 0x7927);
+ dev->irq_map = is_mt7927_hw ? &mt7927_irq_map : &irq_map;
mt76_mmio_init(&dev->mt76, pcim_iomap_table(pdev)[0]);
tasklet_init(&mdev->irq_tasklet, mt792x_irq_tasklet, (unsigned long)dev);
@@ -549,7 +563,10 @@ static int _mt7925_pci_resume(struct device *device, bool restore)
mt76_wr(dev, MT_PCIE_MAC_INT_ENABLE, 0xff);
mt76_connac_irq_enable(&dev->mt76,
dev->irq_map->tx.all_complete_mask |
- MT_INT_RX_DONE_ALL | MT_INT_MCU_CMD);
+ dev->irq_map->rx.data_complete_mask |
+ dev->irq_map->rx.wm_complete_mask |
+ dev->irq_map->rx.wm2_complete_mask |
+ MT_INT_MCU_CMD);
mt76_set(dev, MT_MCU2HOST_SW_INT_ENA, MT_MCU_CMD_WAKE_RX_PCIE);
/* put dma enabled */
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
index 3072850c2752..1626a3684082 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci_mac.c
@@ -118,7 +118,10 @@ int mt7925e_mac_reset(struct mt792x_dev *dev)
mt76_wr(dev, dev->irq_map->host_irq_enable,
dev->irq_map->tx.all_complete_mask |
- MT_INT_RX_DONE_ALL | MT_INT_MCU_CMD);
+ dev->irq_map->rx.data_complete_mask |
+ dev->irq_map->rx.wm_complete_mask |
+ dev->irq_map->rx.wm2_complete_mask |
+ MT_INT_MCU_CMD);
mt76_wr(dev, MT_PCIE_MAC_INT_ENABLE, 0xff);
err = mt792xe_mcu_fw_pmctrl(dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
index acf627aed609..a8c8d7d6f565 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
@@ -308,6 +308,9 @@
#define HOST_RX_DONE_INT_ENA1 BIT(1)
#define HOST_RX_DONE_INT_ENA2 BIT(2)
#define HOST_RX_DONE_INT_ENA3 BIT(3)
+#define MT7927_RX_DONE_INT_ENA4 BIT(12)
+#define MT7927_RX_DONE_INT_ENA6 BIT(14)
+#define MT7927_RX_DONE_INT_ENA7 BIT(15)
#define HOST_TX_DONE_INT_ENA0 BIT(4)
#define HOST_TX_DONE_INT_ENA1 BIT(5)
#define HOST_TX_DONE_INT_ENA2 BIT(6)
--
2.53.0
^ permalink raw reply related
* [PATCH v4 7/9] wifi: mt76: mt7925: add MT7927 firmware paths
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
Add firmware path definitions for MT7927 WiFi firmware (WIFI_RAM_CODE
and PATCH_MCU) and the corresponding MODULE_FIRMWARE declarations. Add
MT7927 cases to mt792x_ram_name() and mt792x_patch_name() so the driver
loads the correct firmware for the 0x7927 chip ID.
PCI device table entries are deferred to a later patch to allow
infrastructure setup before device enablement.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 2 ++
drivers/net/wireless/mediatek/mt76/mt792x.h | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
index c4161754c01d..f820d5aeb723 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c
@@ -633,6 +633,8 @@ module_pci_driver(mt7925_pci_driver);
MODULE_DEVICE_TABLE(pci, mt7925_pci_device_table);
MODULE_FIRMWARE(MT7925_FIRMWARE_WM);
MODULE_FIRMWARE(MT7925_ROM_PATCH);
+MODULE_FIRMWARE(MT7927_FIRMWARE_WM);
+MODULE_FIRMWARE(MT7927_ROM_PATCH);
MODULE_AUTHOR("Deren Wu <deren.wu@mediatek.com>");
MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
MODULE_DESCRIPTION("MediaTek MT7925E (PCIe) wireless driver");
diff --git a/drivers/net/wireless/mediatek/mt76/mt792x.h b/drivers/net/wireless/mediatek/mt76/mt792x.h
index 8388638ed550..38790ef83e51 100644
--- a/drivers/net/wireless/mediatek/mt76/mt792x.h
+++ b/drivers/net/wireless/mediatek/mt76/mt792x.h
@@ -45,11 +45,13 @@
#define MT7921_FIRMWARE_WM "mediatek/WIFI_RAM_CODE_MT7961_1.bin"
#define MT7922_FIRMWARE_WM "mediatek/WIFI_RAM_CODE_MT7922_1.bin"
#define MT7925_FIRMWARE_WM "mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin"
+#define MT7927_FIRMWARE_WM "mediatek/mt7927/WIFI_RAM_CODE_MT6639_2_1.bin"
#define MT7920_ROM_PATCH "mediatek/WIFI_MT7961_patch_mcu_1a_2_hdr.bin"
#define MT7921_ROM_PATCH "mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin"
#define MT7922_ROM_PATCH "mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin"
#define MT7925_ROM_PATCH "mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin"
+#define MT7927_ROM_PATCH "mediatek/mt7927/WIFI_MT6639_PATCH_MCU_2_1_hdr.bin"
#define MT792x_SDIO_HDR_TX_BYTES GENMASK(15, 0)
#define MT792x_SDIO_HDR_PKT_TYPE GENMASK(17, 16)
@@ -454,6 +456,8 @@ static inline char *mt792x_ram_name(struct mt792x_dev *dev)
return MT7922_FIRMWARE_WM;
case 0x7925:
return MT7925_FIRMWARE_WM;
+ case 0x7927:
+ return MT7927_FIRMWARE_WM;
default:
return MT7921_FIRMWARE_WM;
}
@@ -468,6 +472,8 @@ static inline char *mt792x_patch_name(struct mt792x_dev *dev)
return MT7922_ROM_PATCH;
case 0x7925:
return MT7925_ROM_PATCH;
+ case 0x7927:
+ return MT7927_ROM_PATCH;
default:
return MT7921_ROM_PATCH;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 6/9] wifi: mt76: mt7925: add MT7927 chip ID helpers
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The MediaTek MT7927 (Filogic 380) combo chip uses MT7927 WiFi silicon
that is architecturally compatible with MT7925. Extend is_mt7925() to
match chip ID 0x7927, and add is_mt7927() for code paths that need
MT7927-specific handling.
Also add 0x7927 to is_mt76_fw_txp() to match MT7925's TXP format.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
index 393a7952f86b..4a63ef4e5c34 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
@@ -174,7 +174,12 @@ extern const struct wiphy_wowlan_support mt76_connac_wowlan_support;
static inline bool is_mt7925(struct mt76_dev *dev)
{
- return mt76_chip(dev) == 0x7925;
+ return mt76_chip(dev) == 0x7925 || mt76_chip(dev) == 0x7927;
+}
+
+static inline bool is_mt7927(struct mt76_dev *dev)
+{
+ return mt76_chip(dev) == 0x7927;
}
static inline bool is_320mhz_supported(struct mt76_dev *dev)
@@ -277,6 +282,7 @@ static inline bool is_mt76_fw_txp(struct mt76_dev *dev)
case 0x7920:
case 0x7922:
case 0x7925:
+ case 0x7927:
case 0x7663:
case 0x7622:
return false;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/9] wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80
and BW = 160, but never sets BW = 320. This means iw phy shows no
320MHz MCS map entries even though the hardware supports 320MHz
operation in the 6GHz band.
Add the missing 320MHz capability bits for 6GHz:
- PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ
- PHY_CAP1: beamformee SS for 320MHz
- PHY_CAP2: sounding dimensions for 320MHz
- PHY_CAP6: MCS15 support for 320MHz width
- MCS/NSS: populate bw._320 maps for 6GHz band
Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since
MT7925 does not support 320MHz operation.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 5 +++++
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 22 +++++++++++++++++++++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac.h b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
index 813d61bffc2c..393a7952f86b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac.h
@@ -177,6 +177,11 @@ static inline bool is_mt7925(struct mt76_dev *dev)
return mt76_chip(dev) == 0x7925;
}
+static inline bool is_320mhz_supported(struct mt76_dev *dev)
+{
+ return mt76_chip(dev) == 0x7927;
+}
+
static inline bool is_mt7920(struct mt76_dev *dev)
{
return mt76_chip(dev) == 0x7920;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index f128a198f81d..cfce851a94e2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -183,6 +183,10 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMER |
IEEE80211_EHT_PHY_CAP0_SU_BEAMFORMEE;
+ if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
+ eht_cap_elem->phy_cap_info[0] |=
+ IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+
eht_cap_elem->phy_cap_info[0] |=
u8_encode_bits(u8_get_bits(sts - 1, BIT(0)),
IEEE80211_EHT_PHY_CAP0_BEAMFORMEE_SS_80MHZ_MASK);
@@ -193,10 +197,20 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
u8_encode_bits(sts - 1,
IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_160MHZ_MASK);
+ if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
+ eht_cap_elem->phy_cap_info[1] |=
+ u8_encode_bits(sts - 1,
+ IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK);
+
eht_cap_elem->phy_cap_info[2] =
u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_80MHZ_MASK) |
u8_encode_bits(sts - 1, IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_160MHZ_MASK);
+ if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76))
+ eht_cap_elem->phy_cap_info[2] |=
+ u8_encode_bits(sts - 1,
+ IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK);
+
eht_cap_elem->phy_cap_info[3] =
IEEE80211_EHT_PHY_CAP3_NG_16_SU_FEEDBACK |
IEEE80211_EHT_PHY_CAP3_NG_16_MU_FEEDBACK |
@@ -217,7 +231,8 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
u8_encode_bits(u8_get_bits(0x11, GENMASK(1, 0)),
IEEE80211_EHT_PHY_CAP5_MAX_NUM_SUPP_EHT_LTF_MASK);
- val = width == NL80211_CHAN_WIDTH_160 ? 0x7 :
+ val = width == NL80211_CHAN_WIDTH_320 ? 0xf :
+ width == NL80211_CHAN_WIDTH_160 ? 0x7 :
width == NL80211_CHAN_WIDTH_80 ? 0x3 : 0x1;
eht_cap_elem->phy_cap_info[6] =
u8_encode_bits(u8_get_bits(0x11, GENMASK(4, 2)),
@@ -239,6 +254,11 @@ mt7925_init_eht_caps(struct mt792x_phy *phy, enum nl80211_band band,
eht_nss->bw._160.rx_tx_mcs9_max_nss = val;
eht_nss->bw._160.rx_tx_mcs11_max_nss = val;
eht_nss->bw._160.rx_tx_mcs13_max_nss = val;
+ if (band == NL80211_BAND_6GHZ && is_320mhz_supported(&phy->dev->mt76)) {
+ eht_nss->bw._320.rx_tx_mcs9_max_nss = val;
+ eht_nss->bw._320.rx_tx_mcs11_max_nss = val;
+ eht_nss->bw._320.rx_tx_mcs13_max_nss = val;
+ }
}
int mt7925_init_mlo_caps(struct mt792x_phy *phy)
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/9] wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel
width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS
map was never copied from the station's EHT capabilities to the MCU TLV.
This prevents negotiation of 320MHz channel width even when both the
hardware and firmware advertise support for it.
Add the missing memcpy for the 320MHz MCS map, matching the existing
pattern for BW20, BW80, and BW160.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index dd5ecb07947b..a7f27c5014d5 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1683,6 +1683,7 @@ mt7925_mcu_sta_eht_tlv(struct sk_buff *skb, struct ieee80211_link_sta *link_sta)
memcpy(eht->mcs_map_bw20, &mcs_map->only_20mhz, sizeof(eht->mcs_map_bw20));
memcpy(eht->mcs_map_bw80, &mcs_map->bw._80, sizeof(eht->mcs_map_bw80));
memcpy(eht->mcs_map_bw160, &mcs_map->bw._160, sizeof(eht->mcs_map_bw160));
+ memcpy(eht->mcs_map_bw320, &mcs_map->bw._320, sizeof(eht->mcs_map_bw320));
}
static void
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/9] wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling
for 320MHz channel width. When the hardware reports 320MHz in the
bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and
mt7925_mac_add_txs_skb() records no bandwidth stats.
Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser
also handles BW_320+1 since the hardware can report 320MHz in two
adjacent encoding positions.
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
index caaf71c31480..ad03fc554b69 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c
@@ -339,6 +339,11 @@ mt7925_mac_fill_rx_rate(struct mt792x_dev *dev,
case IEEE80211_STA_RX_BW_160:
status->bw = RATE_INFO_BW_160;
break;
+ /* RXV can report 320 in two positions */
+ case IEEE80211_STA_RX_BW_320:
+ case IEEE80211_STA_RX_BW_320 + 1:
+ status->bw = RATE_INFO_BW_320;
+ break;
default:
return -EINVAL;
}
@@ -992,6 +997,10 @@ mt7925_mac_add_txs_skb(struct mt792x_dev *dev, struct mt76_wcid *wcid,
stats->tx_mode[mode]++;
switch (FIELD_GET(MT_TXS0_BW, txs)) {
+ case IEEE80211_STA_RX_BW_320:
+ rate.bw = RATE_INFO_BW_320;
+ stats->tx_bw[4]++;
+ break;
case IEEE80211_STA_RX_BW_160:
rate.bw = RATE_INFO_BW_160;
stats->tx_bw[3]++;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/9] wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
张旭涵, Marcin FM, Cristian-Florin Radoi,
George Salukvadze, Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld,
Chapuis Dario, Thibaut François
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for
NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch
falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware
via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz
and cannot decode the AP's 320MHz frames, resulting in complete data
path failure at 320MHz.
Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and
center_chan2.
Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to
841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11.
Reported-by: 张旭涵 <Loong.0x00@gmail.com>
Closes: https://github.com/openwrt/mt76/issues/927
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index cf0fdea45cf7..dd5ecb07947b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -2331,6 +2331,10 @@ void mt7925_mcu_bss_rlm_tlv(struct sk_buff *skb, struct mt76_phy *phy,
case NL80211_CHAN_WIDTH_160:
req->bw = CMD_CBW_160MHZ;
break;
+ case NL80211_CHAN_WIDTH_320:
+ req->bw = CMD_CBW_320MHZ;
+ req->center_chan2 = ieee80211_frequency_to_channel(freq2);
+ break;
case NL80211_CHAN_WIDTH_5:
req->bw = CMD_CBW_5MHZ;
break;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/9] wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260326-mt7927-wifi-support-v4-v4-0-8ab465addcfe@jetm.me>
In the error path of mt7925_change_vif_links(), the free: label iterates
over link_ids to clean up, but compares against `mconf` and `mlink`
which hold stale values from the last loop iteration rather than the
current link_id being freed.
Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare
against the correct per-link pointers.
Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links")
Tested-by: Marcin FM <marcin@lgic.pl>
Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com>
Tested-by: George Salukvadze <giosal90@gmail.com>
Tested-by: Evgeny Kapusta <3193631@gmail.com>
Tested-by: Samu Toljamo <samu.toljamo@gmail.com>
Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com>
Tested-by: Chapuis Dario <chapuisdario4@gmail.com>
Tested-by: Thibaut François <tibo@humeurlibre.fr>
Tested-by: 张旭涵 <Loong.0x00@gmail.com>
Signed-off-by: Javier Tia <floss@jetm.me>
---
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 2d358a96640c..f128a198f81d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -2047,9 +2047,9 @@ mt7925_change_vif_links(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
rcu_assign_pointer(mvif->link_conf[link_id], NULL);
rcu_assign_pointer(mvif->sta.link[link_id], NULL);
- if (mconf != &mvif->bss_conf)
+ if (mconfs[link_id] != &mvif->bss_conf)
devm_kfree(dev->mt76.dev, mconfs[link_id]);
- if (mlink != &mvif->sta.deflink)
+ if (mlinks[link_id] != &mvif->sta.deflink)
devm_kfree(dev->mt76.dev, mlinks[link_id]);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/9] wifi: mt76: mt7925: MT7927 (Filogic 380) support patches 1-9
From: Javier Tia @ 2026-03-26 21:12 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Marcin FM, Cristian-Florin Radoi, George Salukvadze,
Evgeny Kapusta, Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260306-mt7927-wifi-support-v1-0-c77e7445511d@jetm.me>
This series contains the first 9 patches for MediaTek MT7927 (Filogic 380)
combo WiFi 7 + BT 5.4 support in the mt7925 driver.
Patches 1-5 add generic 320MHz EHT support (no MT7927 references).
Patches 6-7 introduce MT7927 chip ID helpers and firmware paths.
Patch 8 adds per-chip IRQ map handling.
Patch 9 disables ASPM and runtime PM for MT7927.
The remaining MT7927-specific patches (DMA configuration, hardware
initialization, band_idx, CNM quirk, and PCI device ID enablement)
will be submitted separately by Sean Wang as part of a broader
refactoring effort to introduce a generic layer that both mt7925 and
mt7927 can share. This split was agreed upon during v3 review.
The DKMS out-of-tree package [1] continues to ship the full patch set
for working hardware support.
[1] https://github.com/jetm/mediatek-mt7927-dkms
Tested hardware:
- ASUS ROG Crosshair X870E Hero (BT 0489:e13a, WiFi 14c3:6639)
- ASUS ProArt X870E-Creator WiFi (BT 0489:e13a / 13d3:3588, WiFi 14c3:6639)
- ASUS ROG Strix X870-I (WiFi 14c3:7927)
- ASUS ROG Strix X870-F Gaming WiFi (BT 0489:e13a, WiFi 14c3:7927)
- ASUS ROG Strix X870E-E (BT 13d3:3588, WiFi 14c3:7927)
- ASUS ROG STRIX B850-E GAMING WIFI (BT 0489:e13a, WiFi 14c3:7927)
- Gigabyte X870E Aorus Master X3D (BT 0489:e10f, WiFi 14c3:7927)
- Gigabyte Z790 AORUS MASTER X (BT 0489:e10f, WiFi 14c3:7927)
- Gigabyte Z790 AORUS ELITE X WiFi7 (BT 0489:e10f, WiFi 14c3:7927)
- MSI MEG X870E ACE MAX (BT 0489:e110, WiFi 14c3:7927)
- Lenovo Legion Pro 7 16ARX9 (BT 0489:e0fa, WiFi 14c3:7927)
- Lenovo Legion Pro 7 16AFR10H (BT 0489:e0fa, WiFi 14c3:7927)
- TP-Link Archer TBE550E PCIe (BT 0489:e116, WiFi 14c3:7927)
- EDUP EP-MT7927BE M.2 card (WiFi 14c3:7927)
- Foxconn/Azurewave M.2 modules (WiFi 14c3:6639)
- AMD RZ738 reference design (WiFi 14c3:0738)
Tested on Arch Linux, CachyOS, EndeavourOS, Fedora (Bazzite), NixOS,
openSUSE Tumbleweed, and Ubuntu across kernels 6.13-6.19.
Changes since v3:
- Dropped patches 9-13 (DMA, HW init, band_idx, PCI IDs). Sean Wang
will submit these as part of a generic layer refactor. The CNM quirk
(v3 patch 13 feedback) will be folded into mt792x_get_mac80211_ops()
as part of that work.
- Fixed is_320mhz_supported() to use mt76_chip() directly instead of
is_mt7927() which was not yet defined at that point (patch 5).
- Trimmed verbose inline comments in ASPM/PM patch per review feedback.
Detail kept in commit message (patch 9).
- Added tested hardware: ASUS ROG STRIX B850-E GAMING WIFI.
Changes since v2 (suggested by Sean Wang):
- Fixed is_320mhz_supported() to check for MT7927 only, not the
entire mt7925 family. MT7925 does not support 320MHz (patch 5).
- Dropped phy_cap_info[7] 320MHz additions (NON_OFDMA_UL_MU_MIMO
and MU_BEAMFORMER) to keep capabilities conservative (patch 5).
- Disabled runtime PM for MT7927 (patch 9). The combo chip shares a
CONNINFRA power domain between WiFi and BT; SET_OWN/CLR_OWN
transitions crash BT firmware. Discovered via user reports of BT
lockups after enabling power_save=1 (Reported-by: Nitin Gurram).
Changes since v1 (suggested by Sean Wang):
- Reorganized from 18 patches into 13 across 8 logical groups
- Common 320MHz patches first, chip-specific changes later
- Introduced mt792x_dma_config struct to reuse mt7925_dma_init()
- Replaced is_mt7927() with is_320mhz_supported() in common patches
Link to v3: https://lore.kernel.org/linux-wireless/20260325-mt7927-wifi-support-v2-v3-0-826feb8fef8e@jetm.me/
Link to v2: https://lore.kernel.org/linux-wireless/20260319-mt7927-wifi-support-v2-v2-0-d627a7fad70d@jetm.me/
Link to v1: https://lore.kernel.org/linux-wireless/20260306-mt7927-wifi-support-v1-0-c77e7445511d@jetm.me/
Signed-off-by: Javier Tia <floss@jetm.me>
---
Javier Tia (9):
wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
wifi: mt76: mt7925: add MT7927 chip ID helpers
wifi: mt76: mt7925: add MT7927 firmware paths
wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
drivers/net/wireless/mediatek/mt76/mt76_connac.h | 13 ++++++++++-
drivers/net/wireless/mediatek/mt76/mt7925/init.c | 3 ++-
drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 ++++++++
drivers/net/wireless/mediatek/mt76/mt7925/main.c | 26 ++++++++++++++++++---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 5 ++++
drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 27 +++++++++++++++++++---
.../net/wireless/mediatek/mt76/mt7925/pci_mac.c | 5 +++-
drivers/net/wireless/mediatek/mt76/mt792x.h | 6 +++++
drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 3 +++
9 files changed, 88 insertions(+), 9 deletions(-)
---
base-commit: 9ac76f3d0bb2940db3a9684d596b9c8f301ef315
change-id: 20260326-mt7927-wifi-support-v4-5fe574b710c6
Best regards,
--
Javier Tia <floss@jetm.me>
^ permalink raw reply
* [PATCH] wifi: mt76: mt7996: limit work in set_bitrate_mask
From: dylan.eskew @ 2026-03-26 20:07 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee
Cc: linux-wireless, shayne.chen, sean.wang, Dylan Eskew
From: Dylan Eskew <dylan.eskew@candelatech.com>
Calls to mt7996_set_bitrate_mask() would propogate work for all stations
on the ieee80211_hw regardless of the vif specified in the call. To
prevent unnecessary work in FW, limit setting the sta_rate to only the
specified vif in mt7996_sta_rate_ctrl_update().
Fixes: afff4325548f0 ("wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback")
Signed-off-by: Dylan Eskew <dylan.eskew@candelatech.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/main.c b/drivers/net/wireless/mediatek/mt76/mt7996/main.c
index a8a6552d49f6..26b8c91db0a8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/main.c
@@ -1959,7 +1959,11 @@ static void mt7996_sta_rate_ctrl_update(void *data, struct ieee80211_sta *sta)
{
struct mt7996_sta *msta = (struct mt7996_sta *)sta->drv_priv;
struct mt7996_sta_link *msta_link;
- u32 *changed = data;
+ struct mt7996_vif *mvif = data;
+ u32 changed = IEEE80211_RC_SUPP_RATES_CHANGED;
+
+ if (msta->vif != mvif)
+ return;
msta_link = rcu_dereference(msta->link[msta->deflink_id]);
if (msta_link)
@@ -1972,7 +1976,6 @@ mt7996_set_bitrate_mask(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
{
struct mt7996_dev *dev = mt7996_hw_dev(hw);
struct mt7996_vif *mvif = (struct mt7996_vif *)vif->drv_priv;
- u32 changed = IEEE80211_RC_SUPP_RATES_CHANGED;
mvif->deflink.bitrate_mask = *mask;
@@ -1985,7 +1988,7 @@ mt7996_set_bitrate_mask(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
* then multiple MCS setting (MCS 4,5,6) is not supported.
*/
ieee80211_iterate_stations_atomic(hw, mt7996_sta_rate_ctrl_update,
- &changed);
+ mvif);
ieee80211_queue_work(hw, &dev->rc_work);
return 0;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v4 2/3] ath10k: Add device-tree quirk to skip host cap QMI requests
From: Paul Sajna @ 2026-03-26 19:39 UTC (permalink / raw)
To: david, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Bjorn Andersson, Konrad Dybcio
Cc: Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-2-bc08538487aa@ixit.cz>
March 25, 2026 at 5:57 PM, "David Heidelberg via B4 Relay" <devnull+david.ixit.cz@kernel.org mailto:devnull+david.ixit.cz@kernel.org?to=%22David%20Heidelberg%20via%20B4%20Relay%22%20%3Cdevnull%2Bdavid.ixit.cz%40kernel.org%3E > wrote:
>
> From: Amit Pundir <amit.pundir@linaro.org>
>
> Some firmware versions do not support the host capability QMI request.
> Since this request occurs before firmware-N.bin and board-M.bin are
> loaded, the quirk cannot be expressed in the firmware itself.
>
> The root cause is unclear, but there appears to be a generation of
> firmware that lacks host capability support.
>
> Without this quirk, ath10k_qmi_host_cap_send_sync() returns
> QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not
> fatal - Wi-Fi services still come up successfully if the request is simply
> skipped.
>
> Add a device-tree quirk to skip the host capability QMI request on devices
> whose firmware does not support it.
>
> For example, firmware build
> "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
> on Xiaomi Poco F1 phone requires this quirk.
>
> Suggested-by: Bjorn Andersson <andersson@kernel.org>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> drivers/net/wireless/ath/ath10k/qmi.c | 13 ++++++++++---
> drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
> drivers/net/wireless/ath/ath10k/snoc.h | 1 +
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index eebd78e7ff6bc..e7f90fd9e9b83 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -808,6 +808,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi *qmi)
> static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> {
> struct ath10k *ar = qmi->ar;
> + struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> int ret;
>
> ret = ath10k_qmi_ind_register_send_sync_msg(qmi);
> @@ -819,9 +820,15 @@ static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> return;
> }
>
> - ret = ath10k_qmi_host_cap_send_sync(qmi);
> - if (ret)
> - return;
> + /*
> + * Skip the host capability request for the firmware versions which
> + * do not support this feature.
> + */
> + if (!test_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags)) {
> + ret = ath10k_qmi_host_cap_send_sync(qmi);
> + if (ret)
> + return;
> + }
>
> ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
> if (ret)
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
> index f72f236fb9eb3..3106502275781 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1362,6 +1362,9 @@ static void ath10k_snoc_quirks_init(struct ath10k *ar)
>
> if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-8bit-quirk"))
> set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags);
> +
> + if (of_property_read_bool(dev->of_node, "qcom,snoc-host-cap-skip-quirk"))
> + set_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags);
> }
>
> int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
> diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
> index 1ecae34687c21..46574fd8f84ee 100644
> --- a/drivers/net/wireless/ath/ath10k/snoc.h
> +++ b/drivers/net/wireless/ath/ath10k/snoc.h
> @@ -51,6 +51,7 @@ enum ath10k_snoc_flags {
> ATH10K_SNOC_FLAG_MODEM_STOPPED,
> ATH10K_SNOC_FLAG_RECOVERY,
> ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
> + ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK,
> };
>
> struct clk_bulk_data;
>
> --
> 2.53.0
>
Tested-by: Paul Sajna <sajattack@postmarketos.org>
^ permalink raw reply
* [wireless-next:main] BUILD SUCCESS 7dd6f81f4ef801b57f6ce7b0eee32aef5c488538
From: kernel test robot @ 2026-03-26 19:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
branch HEAD: 7dd6f81f4ef801b57f6ce7b0eee32aef5c488538 wifi: mac80211: ignore reserved bits in reconfiguration status
elapsed time: 1359m
configs tested: 174
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260326 gcc-8.5.0
arc randconfig-002-20260326 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm keystone_defconfig gcc-15.2.0
arm randconfig-001-20260326 gcc-8.5.0
arm randconfig-002-20260326 gcc-8.5.0
arm randconfig-003-20260326 gcc-8.5.0
arm randconfig-004-20260326 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260326 clang-19
arm64 randconfig-002-20260326 clang-19
arm64 randconfig-003-20260326 clang-19
arm64 randconfig-004-20260326 clang-19
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260326 clang-19
csky randconfig-002-20260326 clang-19
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260326 gcc-8.5.0
hexagon randconfig-002-20260326 gcc-8.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260326 gcc-14
i386 buildonly-randconfig-002-20260326 gcc-14
i386 buildonly-randconfig-003-20260326 gcc-14
i386 buildonly-randconfig-004-20260326 gcc-14
i386 buildonly-randconfig-005-20260326 gcc-14
i386 buildonly-randconfig-006-20260326 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260326 gcc-14
i386 randconfig-002-20260326 gcc-14
i386 randconfig-003-20260326 gcc-14
i386 randconfig-004-20260326 gcc-14
i386 randconfig-005-20260326 gcc-14
i386 randconfig-006-20260326 gcc-14
i386 randconfig-007-20260326 gcc-14
i386 randconfig-011-20260326 clang-20
i386 randconfig-012-20260326 clang-20
i386 randconfig-013-20260326 clang-20
i386 randconfig-014-20260326 clang-20
i386 randconfig-015-20260326 clang-20
i386 randconfig-016-20260326 clang-20
i386 randconfig-017-20260326 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260326 gcc-8.5.0
loongarch randconfig-002-20260326 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
m68k q40_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip30_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260326 gcc-8.5.0
nios2 randconfig-002-20260326 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260326 clang-19
parisc randconfig-002-20260326 clang-19
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260326 clang-19
powerpc randconfig-002-20260326 clang-19
powerpc64 randconfig-001-20260326 clang-19
powerpc64 randconfig-002-20260326 clang-19
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260326 clang-23
riscv randconfig-002-20260326 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260326 clang-23
s390 randconfig-002-20260326 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260326 clang-23
sh randconfig-002-20260326 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260326 gcc-14
sparc randconfig-002-20260326 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260326 gcc-14
sparc64 randconfig-002-20260326 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260326 gcc-14
um randconfig-002-20260326 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260326 clang-20
x86_64 buildonly-randconfig-002-20260326 clang-20
x86_64 buildonly-randconfig-003-20260326 clang-20
x86_64 buildonly-randconfig-004-20260326 clang-20
x86_64 buildonly-randconfig-005-20260326 clang-20
x86_64 buildonly-randconfig-006-20260326 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260326 clang-20
x86_64 randconfig-002-20260326 clang-20
x86_64 randconfig-003-20260326 clang-20
x86_64 randconfig-004-20260326 clang-20
x86_64 randconfig-005-20260326 clang-20
x86_64 randconfig-006-20260326 clang-20
x86_64 randconfig-011-20260326 gcc-14
x86_64 randconfig-012-20260326 gcc-14
x86_64 randconfig-013-20260326 gcc-14
x86_64 randconfig-014-20260326 gcc-14
x86_64 randconfig-015-20260326 gcc-14
x86_64 randconfig-016-20260326 gcc-14
x86_64 randconfig-071-20260326 gcc-14
x86_64 randconfig-072-20260326 gcc-14
x86_64 randconfig-073-20260326 gcc-14
x86_64 randconfig-074-20260326 gcc-14
x86_64 randconfig-075-20260326 gcc-14
x86_64 randconfig-076-20260326 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260326 gcc-14
xtensa randconfig-002-20260326 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH wireless-next] wifi: mt76: mt7925: add Netgear A8500 USB device ID
From: Lucid Duck @ 2026-03-26 19:03 UTC (permalink / raw)
To: nbd, lorenzo.bianconi
Cc: sean.wang, linux-wireless, linux-mediatek, morrownr, stable
Add USB device ID for the Netgear A8500 (0846:9050) which uses
the mt7925 chipset.
Cc: stable@vger.kernel.org
Signed-off-by: Lucid Duck <lucid_duck@justthetip.ca>
---
drivers/net/wireless/mediatek/mt76/mt7925/usb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
index d9968f038..e44f0cafd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/usb.c
@@ -12,6 +12,9 @@
static const struct usb_device_id mt7925u_device_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7925, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
+ /* Netgear, Inc. A8500 */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9050, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
/* Netgear, Inc. A9000 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9072, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)MT7925_FIRMWARE_WM },
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] wireless-2026-03-26
From: Johannes Berg @ 2026-03-26 17:29 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: linux-wireless
In-Reply-To: <936e4100-5e3e-4c3a-8598-6724d904deac@redhat.com>
On Thu, 2026-03-26 at 18:24 +0100, Paolo Abeni wrote:
> On 3/26/26 10:31 AM, Johannes Berg wrote:
> > And ... more fixes from drivers came in, notably iwlwifi with
> > a bunch of things (their maintainer had been on vacation).
> >
> > I'm going to be on vacation next week, but I'm also not aware
> > of anything missing from drivers etc. right now, so we'll see.
> > I doubt this is the _last_ pull request for 7.0, but I think
> > not much more will come in.
> >
> > Please pull and let us know if there's any problem.
>
> Blame on me, I left this one out of my bag, and it missed today net PR
> for Linus.
No worries, I just wanted to get it out before I go mostly offline for
the next week, so it's not stuck on me :)
johannes
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-03-26
From: Paolo Abeni @ 2026-03-26 17:24 UTC (permalink / raw)
To: Johannes Berg, netdev; +Cc: linux-wireless
In-Reply-To: <20260326093329.77815-3-johannes@sipsolutions.net>
On 3/26/26 10:31 AM, Johannes Berg wrote:
> And ... more fixes from drivers came in, notably iwlwifi with
> a bunch of things (their maintainer had been on vacation).
>
> I'm going to be on vacation next week, but I'm also not aware
> of anything missing from drivers etc. right now, so we'll see.
> I doubt this is the _last_ pull request for 7.0, but I think
> not much more will come in.
>
> Please pull and let us know if there's any problem.
Blame on me, I left this one out of my bag, and it missed today net PR
for Linus.
/P
^ 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