* [syzbot] [btrfs?] WARNING in __alloc_workqueue (2)
From: syzbot @ 2026-06-09 23:04 UTC (permalink / raw)
To: clm, dsterba, linux-btrfs, linux-kernel, linux-wireless,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: a87737435cfa Add linux-next specific files for 20260608
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=178a7f2e580000
kernel config: https://syzkaller.appspot.com/x/.config?x=da47745f686dc823
dashboard link: https://syzkaller.appspot.com/bug?extid=f80c62f371ba6a1e7d79
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170260ae580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124f11b6580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/85d19fe6bb4e/disk-a8773743.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/30c683ce26e1/vmlinux-a8773743.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4db5027513d2/bzImage-a8773743.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f80c62f371ba6a1e7d79@syzkaller.appspotmail.com
usb 1-1: config 0 interface 0 altsetting 0 has an invalid descriptor for endpoint zero, skipping
usb 1-1: New USB device found, idVendor=0cf3, idProduct=9374, bcdDevice=bc.3b
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
------------[ cut here ]------------
workqueue: ath6kl_wq is using neither WQ_PERCPU or WQ_UNBOUND. Setting WQ_PERCPU.
WARNING: kernel/workqueue.c:5856 at __alloc_workqueue+0x1d02/0x2070 kernel/workqueue.c:5855, CPU#0: kworker/0:3/5630
Modules linked in:
CPU: 0 UID: 0 PID: 5630 Comm: kworker/0:3 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Workqueue: usb_hub_wq hub_event
RIP: 0010:__alloc_workqueue+0x1d07/0x2070 kernel/workqueue.c:5855
Code: e9 36 f9 ff ff e8 e9 89 37 00 e9 05 fb ff ff e8 df 89 37 00 e9 92 fb ff ff e8 d5 89 37 00 48 8d 3d 1e b7 43 0e 48 8b 74 24 20 <67> 48 0f b9 3a 81 cd 00 01 00 00 e9 88 e5 ff ff e8 b4 89 37 00 48
RSP: 0018:ffffc90004606bc8 EFLAGS: 00010293
RAX: ffffffff818e312b RBX: 0000000000000000 RCX: ffff8880342dbe00
RDX: 0000000000000000 RSI: ffff8880448f3d68 RDI: ffffffff8fd1e850
RBP: 0000000000000000 R08: ffff8880342dbe00 R09: 0000000000000002
R10: 0000000000000100 R11: 0000000000000102 R12: dffffc0000000000
R13: ffff8880448f3c00 R14: ffffc90004606ce0 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff888125a76000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fdb09f620f5 CR3: 0000000028f60000 CR4: 00000000003526f0
Call Trace:
<TASK>
alloc_workqueue_va kernel/workqueue.c:5950 [inline]
alloc_workqueue_noprof+0xe3/0x210 kernel/workqueue.c:5966
ath6kl_usb_create drivers/net/wireless/ath/ath6kl/usb.c:639 [inline]
ath6kl_usb_probe+0xaa/0x1580 drivers/net/wireless/ath/ath6kl/usb.c:1143
usb_probe_interface+0x659/0xc70 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x267/0xaf0 drivers/base/dd.c:706
__driver_probe_device+0x1e2/0x350 drivers/base/dd.c:868
driver_probe_device+0x4f/0x240 drivers/base/dd.c:898
__device_attach_driver+0x270/0x410 drivers/base/dd.c:1026
bus_for_each_drv+0x25b/0x2f0 drivers/base/bus.c:500
__device_attach+0x2c8/0x450 drivers/base/dd.c:1098
device_initial_probe+0xa1/0xd0 drivers/base/dd.c:1153
bus_probe_device+0x12d/0x220 drivers/base/bus.c:620
device_add+0x7ec/0xb90 drivers/base/core.c:3772
usb_set_configuration+0x1a87/0x2110 drivers/usb/core/message.c:2268
usb_generic_driver_probe+0x8d/0x150 drivers/usb/core/generic.c:250
usb_probe_device+0x1c4/0x3b0 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:-1 [inline]
really_probe+0x267/0xaf0 drivers/base/dd.c:706
__driver_probe_device+0x1e2/0x350 drivers/base/dd.c:868
driver_probe_device+0x4f/0x240 drivers/base/dd.c:898
__device_attach_driver+0x270/0x410 drivers/base/dd.c:1026
bus_for_each_drv+0x25b/0x2f0 drivers/base/bus.c:500
__device_attach+0x2c8/0x450 drivers/base/dd.c:1098
device_initial_probe+0xa1/0xd0 drivers/base/dd.c:1153
bus_probe_device+0x12d/0x220 drivers/base/bus.c:620
device_add+0x7ec/0xb90 drivers/base/core.c:3772
usb_new_device+0x9f8/0x16e0 drivers/usb/core/hub.c:2695
hub_port_connect drivers/usb/core/hub.c:5567 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x2a49/0x4f60 drivers/usb/core/hub.c:5953
process_one_work+0x98b/0x1630 kernel/workqueue.c:3326
process_scheduled_works kernel/workqueue.c:3409 [inline]
worker_thread+0xb49/0x1140 kernel/workqueue.c:3490
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: e9 36 f9 ff ff jmp 0xfffff93b
5: e8 e9 89 37 00 call 0x3789f3
a: e9 05 fb ff ff jmp 0xfffffb14
f: e8 df 89 37 00 call 0x3789f3
14: e9 92 fb ff ff jmp 0xfffffbab
19: e8 d5 89 37 00 call 0x3789f3
1e: 48 8d 3d 1e b7 43 0e lea 0xe43b71e(%rip),%rdi # 0xe43b743
25: 48 8b 74 24 20 mov 0x20(%rsp),%rsi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 81 cd 00 01 00 00 or $0x100,%ebp
35: e9 88 e5 ff ff jmp 0xffffe5c2
3a: e8 b4 89 37 00 call 0x3789f3
3f: 48 rex.W
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: (subset) [PATCH v2 00/10] gpiolib: fence off legacy interfaces
From: Kevin Hilman @ 2026-06-09 22:25 UTC (permalink / raw)
To: linux-gpio, Arnd Bergmann
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Thomas Bogendoerfer, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, Matti Vaittinen, Florian Fainelli, Jonas Gorski,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wireless, linux-omap,
linux-arm-kernel, linux-mips, linux-sh, linux-input, linux-leds,
netdev
In-Reply-To: <20260520183815.2510387-1-arnd@kernel.org>
On Wed, 20 May 2026 20:38:05 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This is an update of all the patches that are still required before
> we can actually turn off CONFIG_GPIOLIB_LEGACY for most platforms
> in the final patch of this series.
>
> I originally posted this as a series in
> https://lore.kernel.org/all/20250808151822.536879-1-arnd@kernel.org/
>
> [...]
Applied, thanks!
[09/10] ARM: dts: omap2: add stlc4560 spi-wireless node
commit: c5a0ac76b364bbd1d4fb7e440edabcd2a369343c
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* [PATCH 5.10] wifi: mac80211: check tdls flag in ieee80211_tdls_oper
From: Alexey Panov @ 2026-06-09 18:11 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman
Cc: Alexey Panov, Johannes Berg, David S. Miller, Jakub Kicinski,
linux-wireless, netdev, linux-kernel, lvc-project,
syzbot+56b6a844a4ea74487b7b, Deepanshu Kartikey, Johannes Berg
From: Deepanshu Kartikey <kartikey406@gmail.com>
commit 7d73872d949c488a1d7c308031d6a9d89b5e0a8b upstream.
When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the
station exists but not whether it is actually a TDLS station. This
allows the operation to proceed for non-TDLS stations, causing
unintended side effects like modifying channel context and HT
protection before failing.
Add a check for sta->sta.tdls early in the ENABLE_LINK case, before
any side effects occur, to ensure the operation is only allowed for
actual TDLS peers.
Reported-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=56b6a844a4ea74487b7b
Tested-by: syzbot+56b6a844a4ea74487b7b@syzkaller.appspotmail.com
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
Link: https://patch.msgid.link/20260313092417.520807-1-kartikey406@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[ Alexey: Adapted to the older sta_mtx locking and error-handling flow. ]
Signed-off-by: Alexey Panov <apanov@astralinux.ru>
---
Backport fix for CVE-2026-43052
net/mac80211/tdls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index e01e4daeb8cd..66e32f1d0a98 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -1380,7 +1380,7 @@ int ieee80211_tdls_oper(struct wiphy *wiphy, struct net_device *dev,
mutex_lock(&local->sta_mtx);
sta = sta_info_get(sdata, peer);
- if (!sta) {
+ if (!sta || !sta->sta.tdls) {
mutex_unlock(&local->sta_mtx);
ret = -ENOLINK;
break;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v8 2/3] PCI: Add device-specific reset for Qualcomm devices
From: Alex Williamson @ 2026-06-09 17:53 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: bhelgaas, jjohnson, mani, linux-pci, linux-wireless, ath11k,
ath12k, mhi, linux-kernel, alex
In-Reply-To: <20260609163649.319755-3-jtornosm@redhat.com>
On Tue, 9 Jun 2026 18:36:48 +0200
Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote:
> Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
> lack working reset methods for VFIO passthrough scenarios. These devices
> have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> broken bus reset.
>
> The problem manifests in VFIO passthrough scenarios:
>
> - WCN6855 WiFi card (17cb:1103): Normal VM operation works fine, including
> clean shutdown/reboot. However, when the VM terminates uncleanly
> (crash, force-off), VFIO attempts to reset the device before it can
> be assigned to another VM. Without a working reset method, the device
> remains in an undefined state, preventing reuse.
>
> - WCN7850 WiFi card (17cb:1107): Same behavior as WCN6855.
>
> - SDX62/SDX65 5G modems (17cb:0308): Never successfully initialize even
> on first VM assignment without proper reset capability.
>
> Add device-specific reset entries for these Qualcomm devices using D3cold
> power cycling with automatic D3hot fallback. The implementation uses
> pci_set_power_state(D3cold) which automatically falls back to D3hot on
> platforms without ACPI _PR3 power resources. While not a complete reset
> (BARs preserved), testing shows D3hot transition provides sufficient reset
> for VFIO reuse.
>
> Extract a shared pci_dev_d3cold_d0_cycle() helper function to avoid code
> duplication between pci_d3cold_reset() (strict _PR3 requirement) and the
> new reset_d3cold_d3hot() device-specific reset (automatic fallback).
> The helper performs only the power cycle; IOMMU handling is done by the
> caller (pci_d3cold_reset() for general method, __pci_dev_specific_reset()
> wrapper for device-specific methods).
>
> Device-specific reset is position #1 in the reset hierarchy, so these
> Qualcomm devices will use power cycling as their primary reset method,
> with the general d3cold method (position #8) available as a fallback on
> _PR3-capable platforms if users override via sysfs.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> v8: Fix commit message: correct IOMMU handling description. The helper
> performs only the power cycle; IOMMU is handled by callers (this was
> v6 fix)
> v7: https://lore.kernel.org/all/20260603105853.326290-3-jtornosm@redhat.com/
>
> drivers/pci/pci.c | 37 +++++++++++++++++++++++++++----------
> drivers/pci/pci.h | 1 +
> drivers/pci/quirks.c | 19 +++++++++++++++++++
> 3 files changed, 47 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 096868f80cd4..f7a7443287fd 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4491,6 +4491,32 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
> return ret;
> }
>
> +/**
> + * pci_dev_d3cold_d0_cycle - Perform D3cold->D0 power cycle
> + * @dev: Device to power cycle
> + *
> + * Common helper to perform D3cold->D0 power cycle for reset methods.
> + * Attempts D3cold transition with automatic fallback to D3hot on platforms
> + * without ACPI _PR3 power resources.
> + *
> + * Caller must handle IOMMU preparation/cleanup if needed.
> + *
> + * Returns 0 on success, negative error code on failure.
> + */
> +int pci_dev_d3cold_d0_cycle(struct pci_dev *dev)
> +{
> + int ret;
> +
> + if (dev->current_state != PCI_D0)
> + return -EINVAL;
> +
> + ret = pci_set_power_state(dev, PCI_D3cold);
> + if (ret)
> + return ret;
> +
> + return pci_set_power_state(dev, PCI_D0);
> +}
> +
> /**
> * pci_d3cold_reset - Put device into D3cold and back to D0 for reset
> * @dev: PCI device to reset
> @@ -4520,22 +4546,13 @@ static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
> if (probe)
> return 0;
>
> - if (dev->current_state != PCI_D0)
> - return -EINVAL;
> -
> ret = pci_dev_reset_iommu_prepare(dev);
> if (ret) {
> pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
> return ret;
> }
>
> - ret = pci_set_power_state(dev, PCI_D3cold);
> - if (ret)
> - goto done;
> -
> - ret = pci_set_power_state(dev, PCI_D0);
> -
> -done:
> + ret = pci_dev_d3cold_d0_cycle(dev);
> pci_dev_reset_iommu_done(dev);
> return ret;
> }
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4a14f88e543a..a9942787de9e 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -234,6 +234,7 @@ void pci_init_reset_methods(struct pci_dev *dev);
> int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
> int pci_bus_error_reset(struct pci_dev *dev);
> int pci_try_reset_bridge(struct pci_dev *bridge);
> +int pci_dev_d3cold_d0_cycle(struct pci_dev *dev);
>
> struct pci_cap_saved_data {
> u16 cap_nr;
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index e49136ac5dbf..70f3b0f26799 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4237,6 +4237,22 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
> return 0;
> }
>
> +/*
> + * Device-specific reset method via D3cold/D3hot power cycle.
> + *
> + * Some devices lack working FLR, advertise NoSoftRst+ (blocking PM reset),
> + * and have broken bus reset. This function provides device-specific reset via
> + * power cycling, attempting D3cold with automatic fallback to D3hot on platforms
> + * without ACPI _PR3 power resources.
> + */
My only complaint is that this is positioned a bit generically. If the
reset only achieves D3hot on a device that reports NoSoftRst+, then
this appears as a no-op reset method. The claim here is instead that
despite reporting NoSoftRst+, the devices using this reset have notably
improved behavior, especially across unexpected resets in device
assignment scenarios. This leads us to believe that some degree of
reset is achieved, for devices that otherwise have no viable
alternative reset method.
Also, I know from previous discussions that much of the testing was
done with M.2 adapters in slots without _PR3 support, which exercises
the D3hot fallback rather than an actual D3cold power cycle. Has each
of these devices been tested on a platform where D3cold is actually
achieved through this method? Thanks,
Alex
> +static int reset_d3cold_d3hot(struct pci_dev *dev, bool probe)
> +{
> + if (probe)
> + return 0;
> +
> + return pci_dev_d3cold_d0_cycle(dev);
> +}
> +
> static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
> reset_intel_82599_sfp_virtfn },
> @@ -4252,6 +4268,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
> reset_chelsio_generic_dev },
> { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
> reset_hinic_vf_dev },
> + { PCI_VENDOR_ID_QCOM, 0x1103, reset_d3cold_d3hot }, /* WCN6855 */
> + { PCI_VENDOR_ID_QCOM, 0x1107, reset_d3cold_d3hot }, /* WCN7850 */
> + { PCI_VENDOR_ID_QCOM, 0x0308, reset_d3cold_d3hot }, /* SDX62/SDX65 */
> { 0 }
> };
>
^ permalink raw reply
* Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925
From: Alex Williamson @ 2026-06-09 16:44 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: helgaas, bhelgaas, linux-kernel, linux-pci, linux-wireless,
lorenzo, nbd, sean.wang, shayne.chen, alex
In-Reply-To: <20260609153333.70991-1-jtornosm@redhat.com>
On Tue, 9 Jun 2026 17:33:33 +0200
Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote:
> Hello Bjorn,
>
>
> > Alex, are you OK with this? The v2 conversation talks about SBR also
> > being broken, but maybe that turned out to be a red herring?
> >
> > https://lore.kernel.org/linux-pci/20260508145153.717641-1-jtornosm@redhat.com/t/#u
> Alex can answer better, but to clarify: SBR works correctly for MT7925e.
> The confusion in v2 was because I initially grouped MT7925e together with
> Qualcomm devices (WCN6855, WCN7850, SDX modems) to try to fix their reset
> issues. Alex suggested testing SBR for all of them, which revealed they
> have different issues:
> - MT7925e: FLR advertised but broken, SBR works fine (this patch - quirk_no_flr)
> - Qualcomm devices: No FLR capability, SBR is broken (separate series with
> quirk_no_bus_reset + device-specific reset)
> So I split them into separate patches since the root causes are different.
> This fix for MT7925e (quirk_no_flr) removes the broken FLR and allows the
> working SBR to be used.
Yes, this patch follows our standard practice of quirking out known
broken reset mechanisms and the qcom devices are now handled in a
different series. I'm ok with this. Thanks,
Alex
^ permalink raw reply
* [PATCH v8 3/3] PCI: Disable broken bus reset on Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-09 16:36 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260609163649.319755-1-jtornosm@redhat.com>
Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
do not properly support Secondary Bus Reset (SBR).
Testing confirms this is device-specific, not deployment-specific:
MediaTek MT7925e successfully uses bus reset through the same passive
M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is
properly wired through the adapters.
This quirk acts as a safety net, preventing the broken bus reset from being
attempted if users override reset methods (device_specific or d3cold when
available) via sysfs.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v8: code unchanged from v7
v7: https://lore.kernel.org/all/20260603105853.326290-4-jtornosm@redhat.com/
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 000000000000..111111111111 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3789,6 +3789,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0032, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003e, quirk_no_bus_reset);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1103, quirk_no_bus_reset); /* WCN6855 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1107, quirk_no_bus_reset); /* WCN7850 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x0308, quirk_no_bus_reset); /* SDX62/SDX65 */
/*
* Root port on some Cavium CN8xxx chips do not successfully complete a bus
--
2.53.0
^ permalink raw reply related
* [PATCH v8 2/3] PCI: Add device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-09 16:36 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260609163649.319755-1-jtornosm@redhat.com>
Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.
The problem manifests in VFIO passthrough scenarios:
- WCN6855 WiFi card (17cb:1103): Normal VM operation works fine, including
clean shutdown/reboot. However, when the VM terminates uncleanly
(crash, force-off), VFIO attempts to reset the device before it can
be assigned to another VM. Without a working reset method, the device
remains in an undefined state, preventing reuse.
- WCN7850 WiFi card (17cb:1107): Same behavior as WCN6855.
- SDX62/SDX65 5G modems (17cb:0308): Never successfully initialize even
on first VM assignment without proper reset capability.
Add device-specific reset entries for these Qualcomm devices using D3cold
power cycling with automatic D3hot fallback. The implementation uses
pci_set_power_state(D3cold) which automatically falls back to D3hot on
platforms without ACPI _PR3 power resources. While not a complete reset
(BARs preserved), testing shows D3hot transition provides sufficient reset
for VFIO reuse.
Extract a shared pci_dev_d3cold_d0_cycle() helper function to avoid code
duplication between pci_d3cold_reset() (strict _PR3 requirement) and the
new reset_d3cold_d3hot() device-specific reset (automatic fallback).
The helper performs only the power cycle; IOMMU handling is done by the
caller (pci_d3cold_reset() for general method, __pci_dev_specific_reset()
wrapper for device-specific methods).
Device-specific reset is position #1 in the reset hierarchy, so these
Qualcomm devices will use power cycling as their primary reset method,
with the general d3cold method (position #8) available as a fallback on
_PR3-capable platforms if users override via sysfs.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v8: Fix commit message: correct IOMMU handling description. The helper
performs only the power cycle; IOMMU is handled by callers (this was
v6 fix)
v7: https://lore.kernel.org/all/20260603105853.326290-3-jtornosm@redhat.com/
drivers/pci/pci.c | 37 +++++++++++++++++++++++++++----------
drivers/pci/pci.h | 1 +
drivers/pci/quirks.c | 19 +++++++++++++++++++
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 096868f80cd4..f7a7443287fd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4491,6 +4491,32 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
return ret;
}
+/**
+ * pci_dev_d3cold_d0_cycle - Perform D3cold->D0 power cycle
+ * @dev: Device to power cycle
+ *
+ * Common helper to perform D3cold->D0 power cycle for reset methods.
+ * Attempts D3cold transition with automatic fallback to D3hot on platforms
+ * without ACPI _PR3 power resources.
+ *
+ * Caller must handle IOMMU preparation/cleanup if needed.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
+int pci_dev_d3cold_d0_cycle(struct pci_dev *dev)
+{
+ int ret;
+
+ if (dev->current_state != PCI_D0)
+ return -EINVAL;
+
+ ret = pci_set_power_state(dev, PCI_D3cold);
+ if (ret)
+ return ret;
+
+ return pci_set_power_state(dev, PCI_D0);
+}
+
/**
* pci_d3cold_reset - Put device into D3cold and back to D0 for reset
* @dev: PCI device to reset
@@ -4520,22 +4546,13 @@ static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
if (probe)
return 0;
- if (dev->current_state != PCI_D0)
- return -EINVAL;
-
ret = pci_dev_reset_iommu_prepare(dev);
if (ret) {
pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
return ret;
}
- ret = pci_set_power_state(dev, PCI_D3cold);
- if (ret)
- goto done;
-
- ret = pci_set_power_state(dev, PCI_D0);
-
-done:
+ ret = pci_dev_d3cold_d0_cycle(dev);
pci_dev_reset_iommu_done(dev);
return ret;
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a..a9942787de9e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -234,6 +234,7 @@ void pci_init_reset_methods(struct pci_dev *dev);
int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
int pci_bus_error_reset(struct pci_dev *dev);
int pci_try_reset_bridge(struct pci_dev *bridge);
+int pci_dev_d3cold_d0_cycle(struct pci_dev *dev);
struct pci_cap_saved_data {
u16 cap_nr;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e49136ac5dbf..70f3b0f26799 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4237,6 +4237,22 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
return 0;
}
+/*
+ * Device-specific reset method via D3cold/D3hot power cycle.
+ *
+ * Some devices lack working FLR, advertise NoSoftRst+ (blocking PM reset),
+ * and have broken bus reset. This function provides device-specific reset via
+ * power cycling, attempting D3cold with automatic fallback to D3hot on platforms
+ * without ACPI _PR3 power resources.
+ */
+static int reset_d3cold_d3hot(struct pci_dev *dev, bool probe)
+{
+ if (probe)
+ return 0;
+
+ return pci_dev_d3cold_d0_cycle(dev);
+}
+
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
@@ -4252,6 +4268,9 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
reset_chelsio_generic_dev },
{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
reset_hinic_vf_dev },
+ { PCI_VENDOR_ID_QCOM, 0x1103, reset_d3cold_d3hot }, /* WCN6855 */
+ { PCI_VENDOR_ID_QCOM, 0x1107, reset_d3cold_d3hot }, /* WCN7850 */
+ { PCI_VENDOR_ID_QCOM, 0x0308, reset_d3cold_d3hot }, /* SDX62/SDX65 */
{ 0 }
};
--
2.54.0
^ permalink raw reply related
* [PATCH v8 1/3] PCI: Add d3cold as general reset method
From: Jose Ignacio Tornos Martinez @ 2026-06-09 16:36 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260609163649.319755-1-jtornosm@redhat.com>
Add D3cold power cycle as a general PCI reset method for single-function
devices on platforms with ACPI _PR3 power resources. This provides true
power cycle reset capability when the platform can physically cut power
to the device.
The implementation strictly requires _PR3 to be present - the platform
must be able to control device power. This ensures d3cold only attempts
true power cycling, not falling back to D3hot transitions.
D3cold reset is placed at the end of the reset hierarchy since it requires
specific platform support and should be tried after standard methods.
Reset hierarchy with this change:
1. device_specific
2. acpi
3. flr
4. af_flr
5. pm (D3hot via config space, checks NoSoftRst)
6. bus (SBR)
7. cxl_bus
8. d3cold (NEW - true power cycle, requires _PR3)
This benefits:
- Platforms with _PR3 support
- Single-function devices needing true power cycle
- VFIO passthrough scenarios where FLR/PM unavailable
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v8: code unchanged from v7
v7: https://lore.kernel.org/all/20260603105853.326290-2-jtornosm@redhat.com/
drivers/pci/pci.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 2 +-
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8f7cfcc00090..096868f80cd4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4491,6 +4491,55 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
return ret;
}
+/**
+ * pci_d3cold_reset - Put device into D3cold and back to D0 for reset
+ * @dev: PCI device to reset
+ * @probe: if true, check if D3cold reset is supported; if false, perform reset
+ *
+ * Reset the device by transitioning through D3cold (actual power removal via
+ * platform power control) and back to D0. This requires ACPI _PR3 power
+ * resources to be present - the platform must be able to physically cut power
+ * to the device.
+ *
+ * Only available for single-function devices to avoid affecting other
+ * functions in multi-function devices.
+ *
+ * Returns 0 if device can be/was reset this way, -ENOTTY if not supported,
+ * or other negative error code on failure.
+ */
+static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
+{
+ int ret;
+
+ if (dev->multifunction)
+ return -ENOTTY;
+
+ if (!pci_pr3_present(dev))
+ return -ENOTTY;
+
+ if (probe)
+ return 0;
+
+ if (dev->current_state != PCI_D0)
+ return -EINVAL;
+
+ ret = pci_dev_reset_iommu_prepare(dev);
+ if (ret) {
+ pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", ret);
+ return ret;
+ }
+
+ ret = pci_set_power_state(dev, PCI_D3cold);
+ if (ret)
+ goto done;
+
+ ret = pci_set_power_state(dev, PCI_D0);
+
+done:
+ pci_dev_reset_iommu_done(dev);
+ return ret;
+}
+
/**
* pcie_wait_for_link_status - Wait for link status change
* @pdev: Device whose link to wait for.
@@ -5065,6 +5114,7 @@ const struct pci_reset_fn_method pci_reset_fn_methods[] = {
{ pci_pm_reset, .name = "pm" },
{ pci_reset_bus_function, .name = "bus" },
{ cxl_reset_bus_function, .name = "cxl_bus" },
+ { pci_d3cold_reset, .name = "d3cold" },
};
/**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..1ca7b880ead7 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -51,7 +51,7 @@
PCI_STATUS_PARITY)
/* Number of reset methods used in pci_reset_fn_methods array in pci.c */
-#define PCI_NUM_RESET_METHODS 8
+#define PCI_NUM_RESET_METHODS 9
#define PCI_RESET_PROBE true
#define PCI_RESET_DO_RESET false
--
2.54.0
^ permalink raw reply related
* [PATCH v8 0/3] PCI: Add d3cold and device-specific reset for Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-09 16:36 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
Some PCIe devices lack working reset methods for VFIO passthrough scenarios.
These devices typically have no FLR, advertise NoSoftRst+ (blocking PM reset),
and have broken or unavailable bus reset. When a VM crashes, VFIO cannot reset
the device for reuse without a working reset method.
This series addresses the problem by adding general d3cold infrastructure and
device-specific reset for Qualcomm devices:
**Patch 1/3: d3cold reset method**
Adds D3cold as a general reset method with strict _PR3 requirement. Only
attempts true power cycling via platform control (ACPI _PR3), never falls
back to D3hot. This provides genuine power-off reset on platforms that
support it.
**Patch 2/3: device-specific reset for Qualcomm devices**
Adds device-specific reset entries for Qualcomm WCN6855/WCN7850 WiFi cards and
SDX62/SDX65 modems using D3cold power cycling with automatic D3hot fallback.
Uses pci_set_power_state(D3cold) which automatically falls back to D3hot on
platforms without _PR3. Extracts shared pci_dev_d3cold_d0_cycle() helper to
avoid code duplication with general d3cold method. Device-specific reset is
position #1 in reset hierarchy, providing immediate working reset for these
Qualcomm devices.
**Patch 3/3: Qualcomm quirk_no_bus_reset**
Disables broken bus reset for Qualcomm devices. Testing proves this is
device-specific: MediaTek MT7925e works correctly with bus reset using the
same passive M.2-to-PCIe adapters where Qualcomm devices fail, confirming
PERST# is properly wired and the issue is not deployment-specific. Acts as
safety net to prevent broken SBR if users override via sysfs.
v8: Fix commit message in patch 2/3: correct IOMMU handling description
Patches 1/3 and 3/3 unchanged from v7
v7: https://lore.kernel.org/all/20260603105853.326290-1-jtornosm@redhat.com/
Jose Ignacio Tornos Martinez (3):
PCI: Add d3cold as general reset method
PCI: Add device-specific reset for Qualcomm devices
PCI: Disable broken bus reset on Qualcomm devices
--
2.53.0
^ permalink raw reply
* Re: [PATCH v3 2/3] remoteproc: qcom_wcnss_iris: Add support for WCN3610
From: Jeff Johnson @ 2026-06-09 15:42 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Krzysztof Kozlowski, Kerigan Creighton, linux-wireless,
loic.poulain, wcn36xx, mathieu.poirier, linux-remoteproc,
linux-arm-msm, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
Dmitry Baryshkov
In-Reply-To: <aieCcYXkmDqfb0Bj@baldur>
On 6/8/2026 8:04 PM, Bjorn Andersson wrote:
> On Fri, Jun 05, 2026 at 05:33:22PM -0700, Jeff Johnson wrote:
>> On 3/5/2026 11:25 PM, Krzysztof Kozlowski wrote:
>>> On 06/03/2026 01:43, Kerigan Creighton wrote:
>>>> WCN3610 has the same regulator requirements as
>>>> WCN3620, so in qcom_wcnss_iris, we can use wcn3620_data.
>>>>
>>>> A separate compatible is needed for WCN3610 because the
>>>> wcn36xx driver uses it for chip-specific configuration.
>>>> Specifically, it sets BTC (Bluetooth Coexistence) CFGs,
>>>> disables ENABLE_DYNAMIC_RA_START_RATE, and disables
>>>> STA_POWERSAVE for this specific chip for stable
>>>> functionality.
>>>
>>> This goes to the binding description where you describe the hardware,
>>> how I asked.
>>>
>>> Please wrap commit message according to Linux coding style / submission
>>> process (neither too early nor over the limit):
>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>> This series is sitting in my patchwork queue.
>> Based upon Krzysztof's comments there should be a v4 that moves some
>> descriptive text from 2/3 to 1/3.
>>
>> Bjorn: Once v4 lands, do you want to take this series or should I?
>> (Need to know if I should wait for ACK of 2/3 or give ACK for 3/3).
>>
>
> I don't see any build-time dependencies between patch {1,2} and {3}. So
> I'd suggest that I pick the two remoteproc patches and you pick the WiFi
> patch.
ACK
^ permalink raw reply
* Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925
From: Jose Ignacio Tornos Martinez @ 2026-06-09 15:33 UTC (permalink / raw)
To: helgaas
Cc: alex, bhelgaas, jtornosm, linux-kernel, linux-pci, linux-wireless,
lorenzo, nbd, sean.wang, shayne.chen
In-Reply-To: <20260609144532.GA104629@bhelgaas>
Hello Bjorn,
> Alex, are you OK with this? The v2 conversation talks about SBR also
> being broken, but maybe that turned out to be a red herring?
>
> https://lore.kernel.org/linux-pci/20260508145153.717641-1-jtornosm@redhat.com/t/#u
Alex can answer better, but to clarify: SBR works correctly for MT7925e.
The confusion in v2 was because I initially grouped MT7925e together with
Qualcomm devices (WCN6855, WCN7850, SDX modems) to try to fix their reset
issues. Alex suggested testing SBR for all of them, which revealed they
have different issues:
- MT7925e: FLR advertised but broken, SBR works fine (this patch - quirk_no_flr)
- Qualcomm devices: No FLR capability, SBR is broken (separate series with
quirk_no_bus_reset + device-specific reset)
So I split them into separate patches since the root causes are different.
This fix for MT7925e (quirk_no_flr) removes the broken FLR and allows the
working SBR to be used.
Thanks
Best regards
Jose Ignacio
^ permalink raw reply
* Re: [PATCHv2 wireless-next] wifi: brcm80211: change current_bss to value
From: Arend van Spriel @ 2026-06-09 14:53 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: brcm80211, brcm80211-dev-list.pdl, linux-kernel
In-Reply-To: <20260608052854.11718-1-rosenp@gmail.com>
Op 8 juni 2026 07:29:12 schreef Rosen Penev <rosenp@gmail.com>:
> Change to a single allocation and remove some boilerplate.
I thought current_bss used to be NULL when not associated, but seems my
memory needs to catch up to today's reality....
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> v2: change to value
> .../broadcom/brcm80211/brcmsmac/main.c | 40 +++----------------
> .../broadcom/brcm80211/brcmsmac/main.h | 2 +-
> 2 files changed, 7 insertions(+), 35 deletions(-)
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: brcmfmac: flowring: simplify flow allocation
From: Arend van Spriel @ 2026-06-09 14:48 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: Kees Cook, Gustavo A. R. Silva, brcm80211, brcm80211-dev-list.pdl,
linux-kernel, linux-hardening
In-Reply-To: <20260608051102.6698-1-rosenp@gmail.com>
Op 8 juni 2026 07:11:22 schreef Rosen Penev <rosenp@gmail.com>:
> Use a flexible array member and kzalloc_flex to combine allocations.
> Simplifies code slightly.
>
> Add __counted_by for extra runtime analysis.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/flowring.c | 10 ++--------
> .../wireless/broadcom/brcm80211/brcmfmac/flowring.h | 2 +-
> 2 files changed, 3 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925
From: Bjorn Helgaas @ 2026-06-09 14:45 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, Alex Williamson
Cc: bhelgaas, nbd, lorenzo, shayne.chen, sean.wang, linux-pci,
linux-wireless, linux-kernel
In-Reply-To: <20260522070646.203115-1-jtornosm@redhat.com>
[cc->to: Alex]
On Fri, May 22, 2026 at 09:06:46AM +0200, Jose Ignacio Tornos Martinez wrote:
> The MediaTek MT7925 WiFi device advertises FLR capability, but it does
> not work correctly. This manifests in VFIO passthrough scenarios: normal
> VM operation works fine, including clean shutdown/reboot. However, when
> the VM terminates uncleanly (crash, force-off), VFIO attempts to reset
> the device before it can be assigned to another VM. Because FLR is broken,
> the reset fails preventing reuse.
>
> This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
> Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms.
> The MT7922 issue manifests as config read failures (returning ~0) after
> FLR. The MT7925 shows different behavior: config reads work correctly
> after FLR, but firmware communication fails.
>
> First VM start with MT7925 works fine:
> mt7925e 0000:08:00.0: ASIC revision: 79250000
> mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
> 20260106153120
>
> After force reset or VM crash, when VFIO attempts FLR to reset the device
> for reassignment, firmware initialization fails:
> mt7925e 0000:08:00.0: ASIC revision: 79250000
> mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout
> mt7925e 0000:08:00.0: Failed to get patch semaphore
> [Repeats with increasing sequence numbers 2-10]
> mt7925e 0000:08:00.0: hardware init failed
>
> The driver cannot acquire the patch semaphore needed for firmware
> initialization, indicating that FLR does not properly reset the firmware
> state. The device remains in this broken state until physical power cycle.
>
> Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset,
> which successfully resets the device and allows reinitialization for VFIO
> passthrough reuse.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Applied to pci/virtualization for v7.2, thanks!
Alex, are you OK with this? The v2 conversation talks about SBR also
being broken, but maybe that turned out to be a red herring?
https://lore.kernel.org/linux-pci/20260508145153.717641-1-jtornosm@redhat.com/t/#u
> ---
> v4: Improved commit message with specific dmesg evidence showing firmware
> initialization failure after FLR (Bjorn Helgaas feedback)
> v2: https://lore.kernel.org/all/20260521061205.12727-1-jtornosm@redhat.com/
>
> drivers/pci/quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 000000000000..111111111111 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5607,6 +5607,7 @@
> * Intel 82579LM Gigabit Ethernet Controller 0x1502
> * Intel 82579V Gigabit Ethernet Controller 0x1503
> * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
> + * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
> */
> static void quirk_no_flr(struct pci_dev *dev)
> {
> @@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
>
> /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
> static void quirk_no_flr_snet(struct pci_dev *dev)
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925
From: Bjorn Helgaas @ 2026-06-09 14:39 UTC (permalink / raw)
To: manisadhasivam.linux
Cc: Jose Ignacio Tornos Martinez, linux-pci, linux-wireless,
linux-kernel
In-Reply-To: <CAGyK6cpa89aHZELLBnc9nBwQdivir7-P9_e+CLQKzbzQzXWjsg@mail.gmail.com>
[cc list trimmed]
On Tue, Jun 09, 2026 at 06:36:38AM -0700, manisadhasivam.linux@gmail.com wrote:
> On Fri, 22 May 2026 09:06:46 +0200, Jose Ignacio Tornos Martinez
> <jtornosm@redhat.com> said:
> > The MediaTek MT7925 WiFi device advertises FLR capability, but it does
> > not work correctly. This manifests in VFIO passthrough scenarios: normal
> > VM operation works fine, including clean shutdown/reboot. However, when
> > the VM terminates uncleanly (crash, force-off), VFIO attempts to reset
> > the device before it can be assigned to another VM. Because FLR is broken,
> > the reset fails preventing reuse.
> >
> > This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
> > Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms.
> > The MT7922 issue manifests as config read failures (returning ~0) after
> > FLR. The MT7925 shows different behavior: config reads work correctly
> > after FLR, but firmware communication fails.
> >
> > First VM start with MT7925 works fine:
> > mt7925e 0000:08:00.0: ASIC revision: 79250000
> > mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
> > 20260106153120
> >
> > After force reset or VM crash, when VFIO attempts FLR to reset the device
> > for reassignment, firmware initialization fails:
> > mt7925e 0000:08:00.0: ASIC revision: 79250000
> > mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout
> > mt7925e 0000:08:00.0: Failed to get patch semaphore
> > [Repeats with increasing sequence numbers 2-10]
> > mt7925e 0000:08:00.0: hardware init failed
> >
> > The driver cannot acquire the patch semaphore needed for firmware
> > initialization, indicating that FLR does not properly reset the firmware
> > state. The device remains in this broken state until physical power cycle.
> >
> > Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset,
> > which successfully resets the device and allows reinitialization for VFIO
> > passthrough reuse.
> >
> > Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Just FYI, b4 complains:
NOTE: some trailers ignored due to from/email mismatches:
! Trailer: Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Msg From: manisadhasivam.linux@gmail.com <manisadhasivam.linux@gmail.com>
I applied your R-b manually.
^ permalink raw reply
* pull-request: ath-next-20260609
From: Jeff Johnson @ 2026-06-09 14:37 UTC (permalink / raw)
To: linux-wireless, Johannes Berg; +Cc: ath10k, ath11k, ath12k, jjohnson
The following changes since commit a26c2a22e7e88b2b5afb1349f3994fc564c988b1:
Merge tag 'iwlwifi-next-2026-06-03' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next (2026-06-04 13:22:11 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git tags/ath-next-20260609
for you to fetch changes up to 63abe299b12b317dfee5bcd09037da4668a4431a:
wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported (2026-06-09 06:50:29 -0700)
----------------------------------------------------------------
ath.git patches for v7.2 (PR #4)
An assortment of cleanups and minor bug fixes across wcn36xx, ath9k,
ath10k, ath11k, and ath12k.
----------------------------------------------------------------
Baochen Qiang (1):
wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
Jeff Johnson (4):
wifi: ath12k: Update Qualcomm copyrights
wifi: ath11k: Update Qualcomm copyrights
wifi: ath10k: Update Qualcomm copyrights
wifi: ath: Update copyright in testmode_i.h
Rosen Penev (6):
wifi: wcn36xx: allocate chan_surveys with main struct
wifi: ath9k_htc: use module_usb_driver
wifi: ath9k: Clear DMA descriptors without memset
wifi: ath9k: remove TX99 power array zero init
wifi: ath9k: remove disabling of bands
wifi: ath9k_htc: allocate tx_buf and buf together
Stepan Ionichev (1):
wifi: wcn36xx: fix spelling mistakes in dxe header comment
Tristan Madani (3):
wifi: wcn36xx: fix heap overflow from oversized firmware HAL response
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
wifi: wcn36xx: fix OOB read from short trigger BA firmware response
Wen Gong (1):
wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
drivers/net/wireless/ath/ath10k/bmi.c | 1 -
drivers/net/wireless/ath/ath10k/ce.c | 1 -
drivers/net/wireless/ath/ath10k/coredump.c | 1 -
drivers/net/wireless/ath/ath10k/coredump.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 1 -
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 1 -
drivers/net/wireless/ath/ath10k/htc.c | 1 -
drivers/net/wireless/ath/ath10k/htt.c | 2 +-
drivers/net/wireless/ath/ath10k/htt.h | 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 1 -
drivers/net/wireless/ath/ath10k/htt_tx.c | 1 -
drivers/net/wireless/ath/ath10k/hw.c | 2 +-
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
drivers/net/wireless/ath/ath10k/pci.c | 1 -
drivers/net/wireless/ath/ath10k/pci.h | 2 +-
drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 2 +-
drivers/net/wireless/ath/ath10k/rx_desc.h | 2 +-
drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
drivers/net/wireless/ath/ath10k/thermal.c | 2 +-
drivers/net/wireless/ath/ath10k/usb.h | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 2 +-
drivers/net/wireless/ath/ath10k/wow.c | 2 +-
drivers/net/wireless/ath/ath11k/ahb.c | 2 +-
drivers/net/wireless/ath/ath11k/ahb.h | 2 +-
drivers/net/wireless/ath/ath11k/ce.c | 1 -
drivers/net/wireless/ath/ath11k/ce.h | 2 +-
drivers/net/wireless/ath/ath11k/coredump.c | 1 -
drivers/net/wireless/ath/ath11k/coredump.h | 2 +-
drivers/net/wireless/ath/ath11k/debug.c | 1 -
drivers/net/wireless/ath/ath11k/debugfs.c | 1 -
drivers/net/wireless/ath/ath11k/debugfs.h | 2 +-
.../net/wireless/ath/ath11k/debugfs_htt_stats.c | 1 -
.../net/wireless/ath/ath11k/debugfs_htt_stats.h | 2 +-
drivers/net/wireless/ath/ath11k/debugfs_sta.h | 2 +-
drivers/net/wireless/ath/ath11k/dp.c | 1 -
drivers/net/wireless/ath/ath11k/dp.h | 2 +-
drivers/net/wireless/ath/ath11k/dp_rx.h | 2 +-
drivers/net/wireless/ath/ath11k/dp_tx.c | 1 -
drivers/net/wireless/ath/ath11k/dp_tx.h | 2 +-
drivers/net/wireless/ath/ath11k/fw.c | 1 -
drivers/net/wireless/ath/ath11k/fw.h | 2 +-
drivers/net/wireless/ath/ath11k/hal_desc.h | 2 +-
drivers/net/wireless/ath/ath11k/hal_rx.c | 2 +-
drivers/net/wireless/ath/ath11k/hal_rx.h | 2 +-
drivers/net/wireless/ath/ath11k/hal_tx.c | 2 +-
drivers/net/wireless/ath/ath11k/hal_tx.h | 2 +-
drivers/net/wireless/ath/ath11k/hif.h | 2 +-
drivers/net/wireless/ath/ath11k/htc.c | 2 +-
drivers/net/wireless/ath/ath11k/htc.h | 2 +-
drivers/net/wireless/ath/ath11k/hw.c | 2 +-
drivers/net/wireless/ath/ath11k/mac.h | 2 +-
drivers/net/wireless/ath/ath11k/mhi.h | 2 +-
drivers/net/wireless/ath/ath11k/p2p.c | 2 +-
drivers/net/wireless/ath/ath11k/p2p.h | 2 +-
drivers/net/wireless/ath/ath11k/pcic.c | 1 -
drivers/net/wireless/ath/ath11k/pcic.h | 2 +-
drivers/net/wireless/ath/ath11k/peer.c | 2 +-
drivers/net/wireless/ath/ath11k/peer.h | 2 +-
drivers/net/wireless/ath/ath11k/qmi.h | 2 +-
drivers/net/wireless/ath/ath11k/reg.h | 2 +-
drivers/net/wireless/ath/ath11k/rx_desc.h | 2 +-
drivers/net/wireless/ath/ath11k/spectral.c | 1 -
drivers/net/wireless/ath/ath11k/spectral.h | 2 +-
drivers/net/wireless/ath/ath11k/testmode.c | 2 +-
drivers/net/wireless/ath/ath11k/testmode.h | 2 +-
drivers/net/wireless/ath/ath11k/thermal.c | 2 +-
drivers/net/wireless/ath/ath11k/thermal.h | 2 +-
drivers/net/wireless/ath/ath11k/trace.h | 2 +-
drivers/net/wireless/ath/ath11k/wow.c | 2 +-
drivers/net/wireless/ath/ath11k/wow.h | 2 +-
drivers/net/wireless/ath/ath12k/acpi.c | 2 +-
drivers/net/wireless/ath/ath12k/acpi.h | 2 +-
drivers/net/wireless/ath/ath12k/coredump.c | 2 +-
drivers/net/wireless/ath/ath12k/coredump.h | 2 +-
drivers/net/wireless/ath/ath12k/dbring.h | 2 +-
drivers/net/wireless/ath/ath12k/debug.h | 2 +-
drivers/net/wireless/ath/ath12k/debugfs.h | 2 +-
drivers/net/wireless/ath/ath12k/debugfs_sta.h | 2 +-
drivers/net/wireless/ath/ath12k/dp.c | 10 ++++-----
drivers/net/wireless/ath/ath12k/hif.h | 2 +-
drivers/net/wireless/ath/ath12k/mac.c | 4 ++++
drivers/net/wireless/ath/ath12k/p2p.c | 1 -
drivers/net/wireless/ath/ath12k/p2p.h | 2 +-
drivers/net/wireless/ath/ath12k/reg.c | 2 +-
drivers/net/wireless/ath/ath12k/reg.h | 2 +-
drivers/net/wireless/ath/ath12k/testmode.h | 2 +-
drivers/net/wireless/ath/ath12k/trace.c | 2 +-
drivers/net/wireless/ath/ath12k/trace.h | 2 +-
drivers/net/wireless/ath/ath12k/wow.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 15 +++++++++++++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 23 +++++++++++++++++----
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 4 ++--
drivers/net/wireless/ath/ath9k/hif_usb.c | 24 +++-------------------
drivers/net/wireless/ath/ath9k/hif_usb.h | 4 +---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 18 ----------------
drivers/net/wireless/ath/ath9k/hw.c | 16 ++++-----------
drivers/net/wireless/ath/ath9k/hw.h | 2 --
drivers/net/wireless/ath/testmode_i.h | 2 +-
drivers/net/wireless/ath/wcn36xx/dxe.c | 4 ++--
drivers/net/wireless/ath/wcn36xx/main.c | 13 ++----------
drivers/net/wireless/ath/wcn36xx/smd.c | 13 ++++++++++++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +-
103 files changed, 139 insertions(+), 171 deletions(-)
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
From: Jeff Johnson @ 2026-06-09 13:55 UTC (permalink / raw)
To: ath12k, Maharaja Kennadyrajan; +Cc: linux-wireless, Wen Gong
In-Reply-To: <20260604095831.2674298-1-maharaja.kennadyrajan@oss.qualcomm.com>
On Thu, 04 Jun 2026 15:28:31 +0530, Maharaja Kennadyrajan wrote:
> When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in
> ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the
> advertisement valid.
>
> According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and
> NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA
> is capable of interpreting the Extended NSS BW Support subfield of the VHT
> capabilities information field. Advertising extended NSS BW support without
> setting this capability bit is therefore invalid.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
commit: 63abe299b12b317dfee5bcd09037da4668a4431a
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
From: Jeff Johnson @ 2026-06-09 13:55 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang; +Cc: linux-wireless, ath12k
In-Reply-To: <20260609-ath12k-fix-eapol-tcl-metadata-v1-1-d47e6f90d4ee@oss.qualcomm.com>
On Tue, 09 Jun 2026 10:10:47 +0800, Baochen Qiang wrote:
> On WCN7850, after the following sequence:
>
> 1. load ath12k and connect to a non-MLO AP
> 2. disconnect and connect to an MLO AP
> 3. disconnect and reconnect to the non-MLO AP
>
> the third connection always fails with a 4-Way handshake timeout. The
> supplicant transmits message 2 of 4 four times in response to AP
> retries of message 1, but the AP never sees any of them.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
commit: fdea4d44e4b9c3f7021c85f8cd766e84e224472d
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2 0/4] wifi: ath: Update copyrights
From: Jeff Johnson @ 2026-06-09 13:55 UTC (permalink / raw)
To: Jeff Johnson, Jeff Johnson
Cc: linux-wireless, ath12k, linux-kernel, ath11k, ath10k
In-Reply-To: <20260608-ath12k-copyright-v2-0-37504d70b03c@oss.qualcomm.com>
On Mon, 08 Jun 2026 06:21:31 -0700, Jeff Johnson wrote:
> Update the Qualcomm copyrights in the ath wireless drivers that were
> substantially contributed by Qualcomm using the current guidance from
> the legal team.
>
Applied, thanks!
[1/4] wifi: ath12k: Update Qualcomm copyrights
commit: 1c316d02c399e5efb1279666c078f99b3f72b0ca
[2/4] wifi: ath11k: Update Qualcomm copyrights
commit: 053a93808d4654fae18633b01a747caa7a281aaa
[3/4] wifi: ath10k: Update Qualcomm copyrights
commit: ae667b0f98b80146ea22830a1b53c5758ad742f1
[4/4] wifi: ath: Update copyright in testmode_i.h
commit: 21d83c6e9e45156f4cad8c7cd6fc2d5bbc76f73e
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925
From: manisadhasivam.linux @ 2026-06-09 13:36 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: nbd, lorenzo, shayne.chen, sean.wang, linux-pci, linux-wireless,
linux-kernel, bhelgaas, alex
In-Reply-To: <20260522070646.203115-1-jtornosm@redhat.com>
On Fri, 22 May 2026 09:06:46 +0200, Jose Ignacio Tornos Martinez
<jtornosm@redhat.com> said:
> The MediaTek MT7925 WiFi device advertises FLR capability, but it does
> not work correctly. This manifests in VFIO passthrough scenarios: normal
> VM operation works fine, including clean shutdown/reboot. However, when
> the VM terminates uncleanly (crash, force-off), VFIO attempts to reset
> the device before it can be assigned to another VM. Because FLR is broken,
> the reset fails preventing reuse.
>
> This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
> Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms.
> The MT7922 issue manifests as config read failures (returning ~0) after
> FLR. The MT7925 shows different behavior: config reads work correctly
> after FLR, but firmware communication fails.
>
> First VM start with MT7925 works fine:
> mt7925e 0000:08:00.0: ASIC revision: 79250000
> mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
> 20260106153120
>
> After force reset or VM crash, when VFIO attempts FLR to reset the device
> for reassignment, firmware initialization fails:
> mt7925e 0000:08:00.0: ASIC revision: 79250000
> mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout
> mt7925e 0000:08:00.0: Failed to get patch semaphore
> [Repeats with increasing sequence numbers 2-10]
> mt7925e 0000:08:00.0: hardware init failed
>
> The driver cannot acquire the patch semaphore needed for firmware
> initialization, indicating that FLR does not properly reset the firmware
> state. The device remains in this broken state until physical power cycle.
>
> Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset,
> which successfully resets the device and allows reinitialization for VFIO
> passthrough reuse.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> v4: Improved commit message with specific dmesg evidence showing firmware
> initialization failure after FLR (Bjorn Helgaas feedback)
> v2: https://lore.kernel.org/all/20260521061205.12727-1-jtornosm@redhat.com/
>
> drivers/pci/quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 000000000000..111111111111 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5607,6 +5607,7 @@
> * Intel 82579LM Gigabit Ethernet Controller 0x1502
> * Intel 82579V Gigabit Ethernet Controller 0x1503
> * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
> + * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
> */
> static void quirk_no_flr(struct pci_dev *dev)
> {
> @@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
>
> /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
> static void quirk_no_flr_snet(struct pci_dev *dev)
> --
> 2.53.0
>
>
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] wifi: mac80211_hwsim: fix destroy-on-close UAF in netlink handlers
From: Johannes Berg @ 2026-06-09 12:34 UTC (permalink / raw)
To: Dominik 'Disconnect3d' Czarnota
Cc: Jukka Rissanen, linux-wireless, linux-kernel
In-Reply-To: <20260609093408.2777763-1-dominik.czarnota@trailofbits.com>
On Tue, 2026-06-09 at 09:32 +0000, Dominik 'Disconnect3d' Czarnota
wrote:
> mac80211_hwsim is a developer testing driver for simulated 802.11
> radios and is not used for normal wireless LAN operation.
>
> Its generic-netlink handlers can look up a radio by MAC address and then
> continue using the returned hwsim data after the rhashtable lookup has
> completed. A destroy_on_close netlink socket can concurrently remove that
> radio from the global table and unregister/free the ieee80211_hw, leaving
> the handler with stale hwsim_data, wdev or PMSR request pointers. This
> can lead to a use-after-free.
>
> Make address lookup take an active radio reference under hwsim_radio_lock.
> Drop that reference at the end of each netlink handler that uses the
> lookup helper. During radio deletion, drop the initial reference and wait
> for active handlers to finish before unregistering and freeing the hw.
The whole refcount here is overblown, could just use RCU, and the patch
doesn't apply either.
johannes
^ permalink raw reply
* Re: [PATCH v3] wifi: mt76: mt76u: use a threaded NAPI for the RX path
From: Lorenzo Bianconi @ 2026-06-09 12:18 UTC (permalink / raw)
To: Filip Bakreski; +Cc: nbd, ryder.lee, shayne.chen, sean.wang, linux-wireless
In-Reply-To: <20260609105301.196302-1-phial@phiality.com>
[-- Attachment #1: Type: text/plain, Size: 5709 bytes --]
> The USB RX path delivers frames to the stack via mt76_rx_complete() with
> a NULL napi pointer, taking the netif_receive_skb_list() path, so it never
> benefits from GRO -- unlike the DMA-based mt76 drivers, which pass a real
> napi and use napi_gro_receive(). For bulk TCP traffic this is costly, as
> every segment traverses the stack individually.
>
> Service the MT_RXQ_MAIN queue from a threaded NAPI, reusing mt76_dev's
> existing napi_dev and napi[] rather than adding new fields. The URB
> completion handler schedules the napi; its poll drains the URBs, builds
> the skbs, resubmits and delivers them through napi_gro_receive(). The MCU
> queue stays on the existing RX worker. This enables GRO and moves RX
> processing into its own kernel thread, parallelising the datapath.
>
> On mt7921u at HE-MCS 11 (2x2, 80 MHz; fast.com, multiple streams) this
> averages ~588 Mbit/s, versus ~424 Mbit/s when the same napi is instead
> driven manually from the RX worker, and ~380 Mbit/s for the unmodified
> driver.
>
> Suggested-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Filip Bakreski <phial@phiality.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> v3:
> - Address review nits: add blank lines for readability and use a priv
> pointer for netdev_priv() like mt76_dma_init() (Lorenzo Bianconi).
>
> v2: https://lore.kernel.org/linux-wireless/20260609003224.132191-1-phial@phiality.com/
> v1: https://lore.kernel.org/linux-wireless/20260608044109.31730-1-phial@phiality.com/
>
> drivers/net/wireless/mediatek/mt76/usb.c | 61 +++++++++++++++++++++---
> 1 file changed, 54 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
> index d9638a9b7..77a8e35b1 100644
> --- a/drivers/net/wireless/mediatek/mt76/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> @@ -580,7 +580,11 @@ static void mt76u_complete_rx(struct urb *urb)
>
> q->head = (q->head + 1) % q->ndesc;
> q->queued++;
> - mt76_worker_schedule(&dev->usb.rx_worker);
> +
> + if (q == &dev->q_rx[MT_RXQ_MAIN])
> + napi_schedule(&dev->napi[MT_RXQ_MAIN]);
> + else
> + mt76_worker_schedule(&dev->usb.rx_worker);
> out:
> spin_unlock_irqrestore(&q->lock, flags);
> }
> @@ -618,11 +622,23 @@ mt76u_process_rx_queue(struct mt76_dev *dev, struct mt76_queue *q)
> }
> mt76u_submit_rx_buf(dev, qid, urb);
> }
> - if (qid == MT_RXQ_MAIN) {
> - local_bh_disable();
> - mt76_rx_poll_complete(dev, MT_RXQ_MAIN, NULL);
> - local_bh_enable();
> - }
> +}
> +
> +/* Threaded NAPI poll for the MAIN RX queue: drain URBs, build skbs, resubmit,
> + * then deliver through napi_gro_receive() and let napi_complete() flush GRO.
> + */
> +static int mt76u_napi_poll(struct napi_struct *napi, int budget)
> +{
> + struct mt76_dev *dev = mt76_priv(napi->dev);
> +
> + rcu_read_lock();
> + mt76u_process_rx_queue(dev, &dev->q_rx[MT_RXQ_MAIN]);
> + mt76_rx_poll_complete(dev, MT_RXQ_MAIN, napi);
> + rcu_read_unlock();
> +
> + napi_complete(napi);
> +
> + return 0;
> }
>
> static void mt76u_rx_worker(struct mt76_worker *w)
> @@ -632,8 +648,13 @@ static void mt76u_rx_worker(struct mt76_worker *w)
> int i;
>
> rcu_read_lock();
> - mt76_for_each_q_rx(dev, i)
> + mt76_for_each_q_rx(dev, i) {
> + /* MT_RXQ_MAIN is serviced by the threaded NAPI poll */
> + if (i == MT_RXQ_MAIN)
> + continue;
> +
> mt76u_process_rx_queue(dev, &dev->q_rx[i]);
> + }
> rcu_read_unlock();
> }
>
> @@ -723,6 +744,8 @@ void mt76u_stop_rx(struct mt76_dev *dev)
> int i;
>
> mt76_worker_disable(&dev->usb.rx_worker);
> + if (dev->napi_dev)
> + napi_disable(&dev->napi[MT_RXQ_MAIN]);
>
> mt76_for_each_q_rx(dev, i) {
> struct mt76_queue *q = &dev->q_rx[i];
> @@ -751,6 +774,8 @@ int mt76u_resume_rx(struct mt76_dev *dev)
> }
>
> mt76_worker_enable(&dev->usb.rx_worker);
> + if (dev->napi_dev)
> + napi_enable(&dev->napi[MT_RXQ_MAIN]);
>
> return 0;
> }
> @@ -1051,6 +1076,13 @@ void mt76u_queues_deinit(struct mt76_dev *dev)
> mt76u_stop_rx(dev);
> mt76u_stop_tx(dev);
>
> + /* mt76u_stop_rx() (above) already napi_disable()d the MAIN queue */
> + if (dev->napi_dev) {
> + netif_napi_del(&dev->napi[MT_RXQ_MAIN]);
> + free_netdev(dev->napi_dev);
> + dev->napi_dev = NULL;
> + }
> +
> mt76u_free_rx(dev);
> mt76u_free_tx(dev);
> }
> @@ -1078,6 +1110,7 @@ int __mt76u_init(struct mt76_dev *dev, struct usb_interface *intf,
> {
> struct usb_device *udev = interface_to_usbdev(intf);
> struct mt76_usb *usb = &dev->usb;
> + struct mt76_dev **priv;
> int err;
>
> INIT_WORK(&usb->stat_work, mt76u_tx_status_data);
> @@ -1115,6 +1148,20 @@ int __mt76u_init(struct mt76_dev *dev, struct usb_interface *intf,
> sched_set_fifo_low(usb->rx_worker.task);
> sched_set_fifo_low(usb->status_worker.task);
>
> + /* threaded NAPI on a dummy netdev (reusing mt76_dev's napi_dev/napi[])
> + * services the MAIN RX queue and gives the RX path GRO
> + */
> + dev->napi_dev = alloc_netdev_dummy(sizeof(struct mt76_dev *));
> + if (!dev->napi_dev)
> + return -ENOMEM;
> +
> + priv = netdev_priv(dev->napi_dev);
> + *priv = dev;
> + strscpy(dev->napi_dev->name, "mt76u-rx", sizeof(dev->napi_dev->name));
> + dev->napi_dev->threaded = 1;
> + netif_napi_add(dev->napi_dev, &dev->napi[MT_RXQ_MAIN], mt76u_napi_poll);
> + napi_enable(&dev->napi[MT_RXQ_MAIN]);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(__mt76u_init);
>
> base-commit: 5f6099446d1ddb888e36cdf93b6a0551f05c1267
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
From: Rameshkumar Sundaram @ 2026-06-09 11:11 UTC (permalink / raw)
To: Maharaja Kennadyrajan, ath12k; +Cc: linux-wireless, Wen Gong
In-Reply-To: <20260604095831.2674298-1-maharaja.kennadyrajan@oss.qualcomm.com>
On 6/4/2026 3:28 PM, Maharaja Kennadyrajan wrote:
> From: Wen Gong <quic_wgong@quicinc.com>
>
> When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in
> ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the
> advertisement valid.
>
> According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and
> NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA
> is capable of interpreting the Extended NSS BW Support subfield of the VHT
> capabilities information field. Advertising extended NSS BW support without
> setting this capability bit is therefore invalid.
>
> Without this change, mac80211 detects the inconsistency and logs:
>
> ieee80211 phy0: copying sband (band 1) due to VHT EXT NSS BW flag
>
> This indicates that mac80211 implicitly aligns IEEE80211_VHT_EXT_NSS_BW_CAPABLE
> during ieee80211_register_hw(). Explicitly setting the bit in ath12k avoids this
> fixup and ensures capabilities are advertised correctly by the driver.
>
> This change follows the same approach as the existing ath11k fix.
> https://lore.kernel.org/all/20211013073704.15888-1-wgong@codeaurora.org/
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
>
> Fixes: 18ab9d038fad ("wifi: ath12k: add support for 160 MHz bandwidth")
> Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
From: Rameshkumar Sundaram @ 2026-06-09 11:06 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson; +Cc: linux-wireless, ath12k
In-Reply-To: <20260609-ath12k-fix-eapol-tcl-metadata-v1-1-d47e6f90d4ee@oss.qualcomm.com>
On 6/9/2026 7:40 AM, Baochen Qiang wrote:
> On WCN7850, after the following sequence:
>
> 1. load ath12k and connect to a non-MLO AP
> 2. disconnect and connect to an MLO AP
> 3. disconnect and reconnect to the non-MLO AP
>
> the third connection always fails with a 4-Way handshake timeout. The
> supplicant transmits message 2 of 4 four times in response to AP
> retries of message 1, but the AP never sees any of them.
>
> ath12k_dp_vdev_tx_attach() composes dp_link_vif->tcl_metadata using |=,
> but dp_link_vif is embedded in struct ath12k_dp_vif and its slots are
> reused across vif/peer teardown and setup. Since tcl_metadata is never
> cleared on detach, vdev_id bits from a previous attach remain set when
> the same link slot is reused with a different vdev_id. In this specific
> issue, the same link slot is used for vdev_id 0, then vdev_id 1, then
> vdev_id 0 again, the OR yields tcl_metadata == 0x9, which encodes
> vdev_id 1 in the HTT_TCL_META_DATA_VDEV_ID field even though
> ti.vdev_id is 0. Firmware then routes the EAPOL frame to the wrong
> vdev and the AP never receives message 2.
>
> Use plain assignment instead of |= so the field is fully recomputed
> from the current arvif on every attach.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
>
> Fixes: af66c7640cf9 ("wifi: ath12k: Refactor ath12k_vif structure")
> Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 4/8] block: implement NVMEM provider
From: Bartosz Golaszewski @ 2026-06-09 11:05 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Bartosz Golaszewski
In-Reply-To: <CAFEp6-1syMQsvuQ+dLU39bnDeL5Ok7vK1mA7CS0v1m7cjhyMQw@mail.gmail.com>
On Tue, 9 Jun 2026 12:13:08 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Hi bartosz,
>
...
>>
>> On the other hand, we don't want to not provide the block device just because
>> someone added a DT property on one that's too big. I'd say: warn, but return 0.
>> Does it make sense?
>
> It’s still technically an error in the sense that we cannot provide
> the required nvmem feature. However, it only becomes a real issue if a
> consumer actually attempts to use it.
> Also, the block device should still be added, since the return code
> from add_dev is not checked. In any case, I’m fine with either
> approach, as long as we emit a warning message.
>
We don't check the return value now (why?) but if we ever do, the safer option
is to return 0 IMO.
>>
>> > + }
>> > +
>> > + config.id = NVMEM_DEVID_NONE;
>> > + config.dev = dev;
>> > + config.name = dev_name(dev);
>> > + config.owner = THIS_MODULE;
>> > + config.priv = (void *)(uintptr_t)dev->devt;
>> > + config.reg_read = blk_nvmem_reg_read;
>> > + config.size = bdev_nr_bytes(bdev);
>> > + config.word_size = 1;
>> > + config.stride = 1;
>> > + config.read_only = true;
>> > + config.root_only = true;
>> > + config.ignore_wp = true;
>> > + config.of_node = to_of_node(dev->fwnode);
>> > +
>> > + return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config));
>>
>> And that was a wrong suggestion on my part too because I was under the
>> impression that we're in the probe() path, not device_add(). You can't use
>> devres here as the device at this point is not yet bound and may never be.
>
> So I understand The bd_device is purely a class device with no bus, no driver.
> For driverless devices, devres_release_all() is called explicitly
> within device_del() .
>
Right.
>>
>> Which leads me to the second point: this is not the moment to add the nvmem
>> provider. This should happen at or after probe(). Once nvmem_register()
>> returns, you have a visible nvmem resource but nothing backing it in the block
>> layer.
>
> There is a short window during which a read attempt will 'properly'
> fail, but this does seem somewhat fragile indeed.
>
>> Either do this in block core when registering a new device or schedule
>> a notifier here for the BUS_NOTIFY_BOUND_DRIVER event and do it in the notifier
>> callback.
>
> So in the end, it seems that the simpler and more robust approach is
> probably to move away from the class_interface driver and instead
> register/unregister the nvmem directly in add_disk/del_gendisk.
> If that's ok I will move to this approach in the next version.
>
Yes, I think it's the right approach.
Bart
^ 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