* Re: [PATCH ath-next] wifi: ath12k: use %u for unsigned variables in QMI debug logs
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: Jeff Johnson, Raj Kumar Bhagat; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260623-qmi-debug-log-v1-1-79471aa8b898@oss.qualcomm.com>
On Tue, 23 Jun 2026 09:34:17 +0530, Raj Kumar Bhagat wrote:
> Replace incorrect %d format specifiers with %u for unsigned variables
> in qmi.c debug messages. Also add missing trailing '\n' in log messages
> to ensure proper termination. No functional change intended.
>
> Tested-on: Compile tested only.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: use %u for unsigned variables in QMI debug logs
commit: 26d529b99861707ed0a4c626184b9399bedca808
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Fix inconsistencies in struct qmi_elem_info initializers
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: Jeff Johnson, Raj Kumar Bhagat; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260623-qmi-inconsistencies-v1-1-0fc17f2b8338@oss.qualcomm.com>
On Tue, 23 Jun 2026 09:43:09 +0530, Raj Kumar Bhagat wrote:
> Currently, the struct qmi_elem_info initializers in qmi.c are inconsistent
> in how they align the assignments, with tabs being used in the majority of
> places but spaces being used in some places. In those places replace the
> spaces with tabs for consistency.
>
> Also fix incorrect and missing terminating records in the following
> qmi_elem_info initializers:
> - qmi_wlanfw_shadow_reg_cfg_s_v01_ei[]
> - qmi_wlanfw_mem_ready_ind_msg_v01_ei[]
> - qmi_wlanfw_fw_ready_ind_msg_v01_ei[]
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Fix inconsistencies in struct qmi_elem_info initializers
commit: c29d1550e166598b9ee6d48c488eec0e79f98d52
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [RESEND PATCH 0/2] genirq/ath12k: fallback to threaded NAPI when IRQ affinity is unavailable
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: tglx, jjohnson, Hangtian Zhu; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260519011627.713068-1-hangtian.zhu@oss.qualcomm.com>
On Tue, 19 May 2026 09:16:25 +0800, Hangtian Zhu wrote:
> This series improves ath12k datapath behavior on platforms where the
> effective IRQ path for WLAN MSI interrupts does not support affinity
> setting.
>
> In such setups, DP processing cannot be distributed as intended and can
> become CPU-constrained. The ath12k change switches to threaded NAPI when
> runtime IRQ capability indicates affinity is unavailable.
>
> [...]
Applied, thanks!
[1/2] genirq: export irq_can_set_affinity() for module drivers
commit: 25e638447e329f08febae2b64c7f85b3bb95e998
[2/2] wifi: ath12k: enable threaded NAPI when DP IRQ affinity is unavailable
commit: 74e1a4762c79a2d6879495d83f22b83acc4dae33
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mt76: fix of_get_mac_address error handling
From: Rosen Penev @ 2026-06-30 21:03 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Felix Fietkau, linux-wireless, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Tobias Klausmann,
Klara Modin, Linux kernel regressions list
In-Reply-To: <173df064-f373-4cce-b35f-e52f728be263@leemhuis.info>
On Tue, Jun 30, 2026 at 5:18 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 6/19/26 03:50, Rosen Penev wrote:
> > On Thu Jun 18, 2026 at 4:51 PM PDT, Klara Modin wrote:
> >> On 2026-06-18 16:01:45 -0700, Rosen Penev wrote:
> >>> On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <klarasmodin@gmail.com> wrote:
> >>>> On 2026-04-26 22:17:46 -0700, Rosen Penev wrote:
> >>>>> Check return value instead of is_valid_ether_addr. The latter is handled
> >>>>> by the former.
> >>>>>
> >>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>>>> [...]
> >>>>>>>> Recently I have started to see randomized MAC-addresses on my
> x86 laptop
> >>>> with a MT7922 and the above message printed in the kernel log. I have
> >>>> CONFIG_OF turned on, but since this is an ACPI system the device is not
> >>>> described by any device tree and the earlier of_get_mac_address() likely
> >>>> fails with -ENODEV. Looking at the !CONFIG_OF stub for
> >>>> of_get_mac_address it always returns -ENODEV, meaning this will always
> >>>> randomize the mac in that case too.
> >>
> >>> IIRC, the normal device_get_mac_address supports nvmem now. Does that
> >>> fix your use case?
> >>
> >> I tried this:
> >> [...]
> >> but I still get a random MAC.
> > Then the original patch should be reverted. Unfortunate that it doesn't
> > workq
>
> Happens, no worries, but seems nobody submitted such a revert yet since
> you posted that. Unless I'm missing something -- if so, please do not
> hesitate to tell me!
>
> But if no revert is in the works, could you please submit one, given
> that it was your change that cause the problem?
https://lore.kernel.org/linux-wireless/20260630210215.400379-1-rosenp@gmail.com/T/#u
>
> Side note: Tobias (now CCed) ran into the same problem, too:
> https://lore.kernel.org/all/30a90714-02d8-45f2-a7f1-4cfe0627d50b@skade.local/
>
> Makes me wonder if more people are affected by this and if we should try
> to mainline the revert rather sooner than later.
>
> Ciao, Thorsten
>
> >>>>
> >>>> Reverting this patch fixes the issue and the correct MAC address is
> >>>> used. I'm not sure if there is any case where of_get_mac_addres() could
> >>>> fail in a way that results in a valid MAC address but it seems unlikely
> >>>> to me.
> >>>>
> >>>> Regards,
> >>>> Klara Modin
> >
> >
>
^ permalink raw reply
* [PATCH wireless-next] wifi: mt76: fix MAC address for non OF pcie cards
From: Rosen Penev @ 2026-06-30 21:02 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Rosen Penev, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
If seems the check for err is wrong as the proper macaddr gets written
to from the EEPROM itself. Meaning checking err from of_get_mac_address is
wrong as the proper macaddr has been written by this point.
Fixes: 31ee1582717e ("wifi: mt76: fix of_get_mac_address error handling")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index b99d7452800f..afdb73661866 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -181,7 +181,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
if (err == -EPROBE_DEFER)
return err;
- if (err) {
+ if (!is_valid_ether_addr(phy->macaddr)) {
eth_random_addr(phy->macaddr);
dev_info(dev->dev,
"Invalid MAC address, using random address %pM\n",
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Loic Poulain @ 2026-06-30 19:59 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <20260630180219.GA4139943-robh@kernel.org>
Hi Rob,
On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > Child nodes of a fixed-partitions node are not necessarily partition
> > entries, for example an nvmem-layout node has no reg property. The
> > current code passes a NULL reg pointer and uninitialized len to the
> > length check, which can result in a kernel panic or silent failure to
> > register any partitions.
>
> That does not sound right to me. A fixed-partitions node should only be
> defining partitions with address ranges. I would expect a partition node
> could be nvmem-layout, but not the whole address range. If you wanted
> the latter, then just do:
>
> partitions {
> ...
> };
>
> nvmem-layout {
> ...
> };
In our case, the nvmem-layout needs to be associated with a specific
eMMC hardware partition, nvmem cells can be a simple sub-range within
the global eMMC, each hardware partition (boot0, boot1, user...)
having its own address spaces.
That said, your point about not abusing fixed-partitions is valid. I
initially dropped the compatible = "fixed-partitions" from the
partitions-boot1 node when it only carries an nvmem-layout and no
actual partition entries, making it a plain named container node. But
it's a bit fragile if we want to support both nvmem-layout and
fixed-partitions.
Regarding your expectation of a partition node being a nvmem-layout,
do you mean that the nvmem-layout should live under a fixed-partitions
node? Something along these lines:
partitions-boot1 {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
nvmem@4400 {
reg = <0x4400 0x1000>;
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
wifi_mac_addr: mac-addr@0 {
compatible = "mac-base";
reg = <0x0 0x6>;
#nvmem-cell-cells = <1>;
};
[...]
That makes some sense, this would require extra work for the
emmc/block layer to also associate fwnodes with logical partitions,
not just the whole disk/hw (hw part), Is that the direction you'd like
us to go?
Also, Note that regardless of which approach we settle on, this
specific fix/patch remains necessary to validate the partition node
and prevent NULL-deref.
Regards,
Loic
^ permalink raw reply
* Re: [syzbot] [wireless?] WARNING in mac80211_hwsim_tx (2)
From: syzbot @ 2026-06-30 19:33 UTC (permalink / raw)
To: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <6a00f268.170a0220.1c0296.021c.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: dc59e4fea9d8 Linux 7.2-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f58032580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c3d59be33cf7e9a
dashboard link: https://syzkaller.appspot.com/bug?extid=435fdb053cf98bfa5778
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13a73289580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=135db61e580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-dc59e4fe.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9ee1f0ea24f2/vmlinux-dc59e4fe.xz
kernel image: https://storage.googleapis.com/syzbot-assets/729e963a1370/bzImage-dc59e4fe.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+435fdb053cf98bfa5778@syzkaller.appspotmail.com
mac80211_hwsim hwsim5 wlan1: entered allmulticast mode
------------[ cut here ]------------
hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw)
WARNING: drivers/net/wireless/virtual/mac80211_hwsim_main.c:2248 at mac80211_hwsim_tx+0x1ab4/0x2500 drivers/net/wireless/virtual/mac80211_hwsim_main.c:2248, CPU#0: syz.0.17/5510
Modules linked in:
CPU: 0 UID: 0 PID: 5510 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:mac80211_hwsim_tx+0x1ab4/0x2500 drivers/net/wireless/virtual/mac80211_hwsim_main.c:2248
Code: c6 05 da 65 07 09 01 48 c7 c7 e0 74 7a 8c be 6b 08 00 00 48 c7 c2 20 76 7a 8c e8 a7 d6 8c fa e9 ff ee ff ff e8 7d eb b0 fa 90 <0f> 0b 90 49 bc 00 00 00 00 00 fc ff df e9 dd fe ff ff e8 65 eb b0
RSP: 0018:ffffc9000278efe0 EFLAGS: 00010293
RAX: ffffffff87158693 RBX: 0000000000000000 RCX: ffff888000ad8000
RDX: 0000000000000000 RSI: 0000000000000014 RDI: 00000000000000a0
RBP: ffffc9000278f170 R08: ffff888000ad8000 R09: 000000000000000e
R10: 000000000000000d R11: 0000000000000000 R12: 0000000000000014
R13: ffff8880120b3cb0 R14: 00000000000000a0 R15: 0000000000000030
FS: 000055559073c500(0000) GS:ffff88808c815000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005562391e0138 CR3: 0000000012ea1000 CR4: 0000000000352ef0
Call Trace:
<TASK>
drv_tx net/mac80211/driver-ops.h:38 [inline]
ieee80211_tx_frags+0x3df/0x890 net/mac80211/tx.c:1746
__ieee80211_tx+0x267/0x580 net/mac80211/tx.c:1801
ieee80211_tx+0x312/0x4b0 net/mac80211/tx.c:1984
ieee80211_monitor_start_xmit+0xb33/0x1280 net/mac80211/tx.c:2479
__netdev_start_xmit include/linux/netdevice.h:5400 [inline]
netdev_start_xmit include/linux/netdevice.h:5409 [inline]
xmit_one net/core/dev.c:3889 [inline]
dev_hard_start_xmit+0x2cd/0x830 net/core/dev.c:3905
__dev_queue_xmit+0x1435/0x37f0 net/core/dev.c:4872
packet_snd net/packet/af_packet.c:3082 [inline]
packet_sendmsg+0x3d95/0x5040 net/packet/af_packet.c:3114
sock_sendmsg_nosec+0x13a/0x180 net/socket.c:775
__sock_sendmsg net/socket.c:790 [inline]
__sys_sendto+0x408/0x5a0 net/socket.c:2252
__do_sys_sendto net/socket.c:2259 [inline]
__se_sys_sendto net/socket.c:2255 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2255
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fc04219ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcb766be38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007fc042415fa0 RCX: 00007fc04219ce59
RDX: 0000000000000030 RSI: 0000200000000640 RDI: 0000000000000008
RBP: 00007fc042232e6f R08: 0000200000000380 R09: 0000000000000014
R10: 0000000004000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fc042415fac R14: 00007fc042415fa0 R15: 00007fc042415fa0
</TASK>
---
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.
^ permalink raw reply
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Rob Herring @ 2026-06-30 18:02 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <20260629-block-as-nvmem-v6-1-f02513dcd46d@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> Child nodes of a fixed-partitions node are not necessarily partition
> entries, for example an nvmem-layout node has no reg property. The
> current code passes a NULL reg pointer and uninitialized len to the
> length check, which can result in a kernel panic or silent failure to
> register any partitions.
That does not sound right to me. A fixed-partitions node should only be
defining partitions with address ranges. I would expect a partition node
could be nvmem-layout, but not the whole address range. If you wanted
the latter, then just do:
partitions {
...
};
nvmem-layout {
...
};
Rob
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: fix regulatory.db async firmware request blocking __usermodehelper_disable()
From: Carlos Llamas @ 2026-06-30 17:57 UTC (permalink / raw)
To: Kavita Kavita; +Cc: johannes, linux-wireless
In-Reply-To: <akP0mRFucE7p_P-S@google.com>
On Tue, Jun 30, 2026 at 04:53:45PM +0000, Carlos Llamas wrote:
> On Mon, Jun 29, 2026 at 12:01:59PM +0530, Kavita Kavita wrote:
> > cfg80211 schedules an asynchronous request_firmware() work item for
> > regulatory.db via request_firmware_work_func(). When the direct
> > firmware load fails, _request_firmware() falls back to the sysfs
> > fallback path via firmware_fallback_sysfs(), which blocks indefinitely
> > in wait_for_completion_killable_timeout() waiting for userspace to
> > supply the firmware through the sysfs interface.
> >
> > While this work item is pending, any caller of
> > __usermodehelper_disable() will deadlock attempting to acquire the
> > usermodehelper rwsem for writing, since the sysfs firmware fallback
> > path holds the rwsem for reading and is blocked waiting for userspace
> > response that can never arrive while usermode helpers are being
> > disabled.
> >
> > Observed call traces where system suspend blocked due to regulatory.db
> > async firmware request:
> >
> > kworker/6:3 (pid 194) holding usermodehelper rwsem read lock, blocked
> > waiting for userspace firmware response:
> > wait_for_completion_killable_timeout+0x48
> > firmware_fallback_sysfs+0x270
> > _request_firmware+0x790
> > request_firmware_work_func+0x44
> > process_one_work[jt]+0x59c
> > worker_thread+0x260
> > kthread+0x150
> > ret_from_fork+0x10
> >
> > Caller blocked in __usermodehelper_disable() during system suspend:
> > rwsem_down_write_slowpath+0x768
> > down_write+0x98
> > __usermodehelper_disable+0x3c
> > freeze_processes+0x18
> > pm_suspend+0x320
> > state_store+0x104
> > kernfs_fop_write_iter[jt]+0x168
> > vfs_write+0x270
> > ksys_write+0x78
> >
> > Any service or kernel subsystem invoking __usermodehelper_disable() is
> > susceptible to this hang as long as the regulatory.db sysfs fallback
> > request remains outstanding.
> >
> > Fix this by replacing the unconditional uevent-based load with a
> > two-step approach. First, attempt a synchronous load via
> > request_firmware_direct() at init time. This is fast and
> > non-blocking, if the file is present in standard paths it is loaded
> > immediately with no delay. If not found, the load is deferred to
> > wiphy_regulatory_register() and triggered via
> > firmware_request_nowait_nowarn() only when the first non-self-managed
> > wiphy registers.
> >
> > For self-managed drivers (REGULATORY_WIPHY_SELF_MANAGED), the hang is
> > avoided because wiphy_regulatory_register() handles them separately
> > and the deferred load path is never reached, so the file load is not
> > attempted at all. For this case, regulatory information is obtained
> > from driver/firmware during wiphy registration. For non-self-managed
> > drivers, the file is required and is expected to be present. The
> > deferred load via firmware_request_nowait_nowarn() is triggered only
> > when the first such wiphy registers. This ensures the database is
> > loaded only when it is actually needed, avoiding the sysfs fallback
> > path on systems where the file is absent at init time.
> >
> > Also refactor regdb_fw_cb() into two functions: regdb_load() which
> > validates and stores the firmware image, and regdb_fw_cb_restore()
> > which is the async callback that calls restore_regulatory_settings()
> > to replay all pending regulatory requests (country hints from core,
> > user, driver and country IE) that arrived while the database was not
> > yet available.
> >
> > NOTE:
> > This issue was observed on Android platforms where regulatory.db is
> > absent.
> > Steps to reproduce on Android platforms:
> > 1. Power off the device completely.
> > 2. Connect the charger; the device enters off-mode charging.
> > 3. While in off-mode charging, short press the power key.
>
> Can you confirm that you see this with !FW_LOADER_USER_HELPER_FALLBACK?
> IIUC, this is disabled in Android and shouldn't trigger this path?
Also, you mentioned this happend while on "off-mode charging". So maybe
don't set force_sysfs_fallback and attempt to load cfg8011 module here?
Anyway, this is orthogonal to this patch. It seems that holding the lock
(read) with a long timeout (60sec?) _and_ trigger a suspend right after
will fall under this trap as you mentioned. It seems a fairly easy thing
to reproduce on vanilla distros I would think?
--
Carlos Llamas
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: fix regulatory.db async firmware request blocking __usermodehelper_disable()
From: Carlos Llamas @ 2026-06-30 16:53 UTC (permalink / raw)
To: Kavita Kavita; +Cc: johannes, linux-wireless
In-Reply-To: <20260629063159.3288957-1-kavita.kavita@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 12:01:59PM +0530, Kavita Kavita wrote:
> cfg80211 schedules an asynchronous request_firmware() work item for
> regulatory.db via request_firmware_work_func(). When the direct
> firmware load fails, _request_firmware() falls back to the sysfs
> fallback path via firmware_fallback_sysfs(), which blocks indefinitely
> in wait_for_completion_killable_timeout() waiting for userspace to
> supply the firmware through the sysfs interface.
>
> While this work item is pending, any caller of
> __usermodehelper_disable() will deadlock attempting to acquire the
> usermodehelper rwsem for writing, since the sysfs firmware fallback
> path holds the rwsem for reading and is blocked waiting for userspace
> response that can never arrive while usermode helpers are being
> disabled.
>
> Observed call traces where system suspend blocked due to regulatory.db
> async firmware request:
>
> kworker/6:3 (pid 194) holding usermodehelper rwsem read lock, blocked
> waiting for userspace firmware response:
> wait_for_completion_killable_timeout+0x48
> firmware_fallback_sysfs+0x270
> _request_firmware+0x790
> request_firmware_work_func+0x44
> process_one_work[jt]+0x59c
> worker_thread+0x260
> kthread+0x150
> ret_from_fork+0x10
>
> Caller blocked in __usermodehelper_disable() during system suspend:
> rwsem_down_write_slowpath+0x768
> down_write+0x98
> __usermodehelper_disable+0x3c
> freeze_processes+0x18
> pm_suspend+0x320
> state_store+0x104
> kernfs_fop_write_iter[jt]+0x168
> vfs_write+0x270
> ksys_write+0x78
>
> Any service or kernel subsystem invoking __usermodehelper_disable() is
> susceptible to this hang as long as the regulatory.db sysfs fallback
> request remains outstanding.
>
> Fix this by replacing the unconditional uevent-based load with a
> two-step approach. First, attempt a synchronous load via
> request_firmware_direct() at init time. This is fast and
> non-blocking, if the file is present in standard paths it is loaded
> immediately with no delay. If not found, the load is deferred to
> wiphy_regulatory_register() and triggered via
> firmware_request_nowait_nowarn() only when the first non-self-managed
> wiphy registers.
>
> For self-managed drivers (REGULATORY_WIPHY_SELF_MANAGED), the hang is
> avoided because wiphy_regulatory_register() handles them separately
> and the deferred load path is never reached, so the file load is not
> attempted at all. For this case, regulatory information is obtained
> from driver/firmware during wiphy registration. For non-self-managed
> drivers, the file is required and is expected to be present. The
> deferred load via firmware_request_nowait_nowarn() is triggered only
> when the first such wiphy registers. This ensures the database is
> loaded only when it is actually needed, avoiding the sysfs fallback
> path on systems where the file is absent at init time.
>
> Also refactor regdb_fw_cb() into two functions: regdb_load() which
> validates and stores the firmware image, and regdb_fw_cb_restore()
> which is the async callback that calls restore_regulatory_settings()
> to replay all pending regulatory requests (country hints from core,
> user, driver and country IE) that arrived while the database was not
> yet available.
>
> NOTE:
> This issue was observed on Android platforms where regulatory.db is
> absent.
> Steps to reproduce on Android platforms:
> 1. Power off the device completely.
> 2. Connect the charger; the device enters off-mode charging.
> 3. While in off-mode charging, short press the power key.
Can you confirm that you see this with !FW_LOADER_USER_HELPER_FALLBACK?
IIUC, this is disabled in Android and shouldn't trigger this path?
>
> Fixes: 007f6c5e6eb4 ("cfg80211: support loading regulatory database as firmware file")
> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
> ---
^ permalink raw reply
* Re: [PATCH ath-next v3] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Jeff Johnson @ 2026-06-30 15:53 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260626084327.2022076-1-aaradhana.sahu@oss.qualcomm.com>
On 6/26/2026 1:43 AM, Aaradhana Sahu wrote:
> @@ -2319,11 +2360,14 @@ static void ath12k_qmi_phy_cap_send(struct ath12k_base *ab)
>
> ab->qmi.num_radios = resp.num_phy;
>
> + if (resp.dynamic_ddr_support_valid)
> + ab->qmi.dynamic_ddr_support = resp.dynamic_ddr_support;
> +
> ath12k_dbg(ab, ATH12K_DBG_QMI,
> - "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d\n",
> + "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d dynamic_ddr_valid %u dynamic_ddr_support %u\n",
> resp.single_chip_mlo_support_valid, resp.single_chip_mlo_support,
> - resp.num_phy_valid, resp.num_phy,
> - resp.board_id_valid, resp.board_id);
> + resp.num_phy_valid, resp.num_phy, resp.board_id_valid, resp.board_id,
> + resp.dynamic_ddr_support_valid, resp.dynamic_ddr_support);
Your logging change conflicts with the one in:
wifi: ath12k: use %u for unsigned variables in QMI debug logs
That one is already in my pending queue, so I'll have you rebase once that one
lands in ath-next.
/jeff
^ permalink raw reply
* [PATCH mt76 2/2] wifi: mt76: mt7915: fix net_fill_forward_path for non-DBDC mt7986
From: Zhi-Jun You @ 2026-06-30 15:06 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee
Cc: shayne.chen, sean.wang, linux-wireless, linux-mediatek,
Zhi-Jun You, Benjamin Larsson
In-Reply-To: <20260630150649.1629-1-hujy652@gmail.com>
Current implementation assumes that the hardware supports DBDC or single
band and binds to band0.
This causes net_fill_forward_path to select the wrong queue for non-DBDC
mt7986 because it binds to band1 and getting the following in dmesg:
ieee80211 phy2: WA: --> drop by reaseon:1, msdu id = 0xc002 but failed!
mtk_wed1: error status=00000002
ieee80211 phy2: WA: txblk
10324e00
len = 128
DW0 : 10 00 00 00
DW1 : 00 00 00 00
DW2 : 00 00 00 00
DW3 : 72 0f 94 68
DW4 : 00 00 00 00
DW5 : ff 03 00 00
DW6 : 00 00 3c 40
DW7 : 00 17 dd 14
DW8 : 79 6f 00 00
DW9 : 02 c0 00 00
DW10 : 58 c5 34 10
DW11 : 00 00 00 00
DW12 : 00 06 3e 00
DW13 : 00 00 00 80
DW14 : 10 8c 00 00
DW15 : 00 00 00 00
DW16 : 00 00 00 00
DW17 : 00 00 00 00
DW18 : 00 00 00 00
DW19 : 00 00 00 00
DW20 : 00 00 00 00
DW21 : 00 00 00 00
DW22 : 00 00 00 00
DW23 : 00 00 00 00
DW24 : 00 00 00 00
DW25 : 00 00 00 00
DW26 : 00 00 00 00
DW27 : 00 00 00 00
DW28 : 00 00 00 00
DW29 : 00 00 00 00
DW30 : 00 00 00 00
DW31 : 00 00 00 00
Fix it by using phy->mt76->band_idx for queue when it's non-DBDC and
mt7986.
Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support")
Suggested-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Zhi-Jun You <hujy652@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7915/main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/main.c b/drivers/net/wireless/mediatek/mt76/mt7915/main.c
index 51643a48ed15..1b433733661c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/main.c
@@ -1743,7 +1743,11 @@ mt7915_net_fill_forward_path(struct ieee80211_hw *hw,
path->mtk_wdma.wdma_idx = wed->wdma_idx;
path->mtk_wdma.bss = mvif->mt76.idx;
path->mtk_wdma.wcid = is_mt7915(&dev->mt76) ? msta->wcid.idx : 0x3ff;
- path->mtk_wdma.queue = phy != &dev->phy;
+
+ if (!dev->dbdc_support && is_mt7986(&dev->mt76))
+ path->mtk_wdma.queue = phy->mt76->band_idx;
+ else
+ path->mtk_wdma.queue = phy != &dev->phy;
ctx->dev = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH mt76 1/2] wifi: mt76: wed: fix kernel panic on non-DBDC MT7986
From: Zhi-Jun You @ 2026-06-30 15:06 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee
Cc: shayne.chen, sean.wang, linux-wireless, linux-mediatek,
Zhi-Jun You
In mt76_wed_init_rx_buf, it's hardcoded to use MT_RXQ_MAIN.
But for non-DBDC MT7986 MT_RXQ_BAND1 is used for RX data queue which
leads to kernel panic when attaching WED.
Use the correct RX queue by checking WED version and band_idx.
v2 and band 1 -> MT_RXQ_BAND1
Others -> MT_RXQ_MAIN
Kernel panic:
Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
Internal error: Oops: 0000000096000005 [#1] SMP
CPU: 1 UID: 0 PID: 925 Comm: kmodloader Tainted: G O 6.18.26 #0 NONE
Tainted: [O]=OOT_MODULE
Hardware name: Acer Connect Vero W6m (DT)
pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : page_pool_alloc_frag_netmem+0x1c/0x1bc
lr : page_pool_alloc_frag+0xc/0x34
sp : ffffffc081dab660
x29: ffffffc081dab660 x28: ffffffc081dabc60 x27: ffffff80091af040
x26: 0000008000000000 x25: ffffff80091a8898 x24: ffffff80091a5440
x23: 0000000000001000 x22: 0000000140000000 x21: ffffff80091a2040
x20: ffffff8003f1d780 x19: 0000000000000000 x18: 0000000000000020
x17: ffffffbfbf0ac000 x16: ffffffc080ee0000 x15: ffffff80049d47ca
x14: 000000000000037b x13: 000000000000037b x12: 0000000000000001
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : ffffff8003f1d7c0 x7 : 0000000000000000 x6 : ffffff8003f1d780
x5 : 0000000000000680 x4 : 0000000000000000 x3 : 0000000000002824
x2 : 0000000000000000 x1 : ffffffc081dab71c x0 : 0000000000000000
Call trace:
page_pool_alloc_frag_netmem+0x1c/0x1bc (P)
page_pool_alloc_frag+0xc/0x34
mt76_wed_init_rx_buf+0xf8/0x2ac [mt76]
mtk_wed_start+0x79c/0x12ac
mt7915_dma_start+0x274/0x63c [mt7915e]
mt7915_dma_start+0x5b4/0x63c [mt7915e]
mt7915_dma_init+0x49c/0x81c [mt7915e]
mt7915_register_device+0x24c/0x530 [mt7915e]
mt7915_mmio_probe+0x91c/0x1980 [mt7915e]
platform_probe+0x58/0xa0
really_probe+0xb8/0x2a8
__driver_probe_device+0x74/0x118
driver_probe_device+0x3c/0xe0
__driver_attach+0x88/0x154
bus_for_each_dev+0x60/0xb0
driver_attach+0x20/0x28
bus_add_driver+0xdc/0x200
driver_register+0x64/0x118
__platform_driver_register+0x20/0x30
init_module+0x74/0x1000 [mt7915e]
do_one_initcall+0x4c/0x1f8
do_init_module+0x50/0x210
load_module+0x15f8/0x1b10
__do_sys_init_module+0x1a8/0x260
__arm64_sys_init_module+0x18/0x20
invoke_syscall.constprop.0+0x4c/0xd0
do_el0_svc+0x3c/0xd0
el0_svc+0x18/0x60
el0t_64_sync_handler+0x98/0xdc
el0t_64_sync+0x158/0x15c
Code: aa0003f3 a9025bf5 a90363f7 d2820017 (b9400000)
Signed-off-by: Zhi-Jun You <hujy652@gmail.com>
---
Changes since RFC
- Replace single band with non-DBDC
---
drivers/net/wireless/mediatek/mt76/wed.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/wed.c b/drivers/net/wireless/mediatek/mt76/wed.c
index ed657d952de2..f210a0c57d81 100644
--- a/drivers/net/wireless/mediatek/mt76/wed.c
+++ b/drivers/net/wireless/mediatek/mt76/wed.c
@@ -33,10 +33,15 @@ u32 mt76_wed_init_rx_buf(struct mtk_wed_device *wed, int size)
{
struct mtk_wed_bm_desc *desc = wed->rx_buf_ring.desc;
struct mt76_dev *dev = mt76_wed_to_dev(wed);
- struct mt76_queue *q = &dev->q_rx[MT_RXQ_MAIN];
struct mt76_txwi_cache *t = NULL;
+ struct mt76_queue *q;
int i;
+ if (wed->version == 2 && dev->phy.band_idx)
+ q = &dev->q_rx[MT_RXQ_BAND1];
+ else
+ q = &dev->q_rx[MT_RXQ_MAIN];
+
for (i = 0; i < size; i++) {
dma_addr_t addr;
u32 offset;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs
From: Jeff Johnson @ 2026-06-30 14:56 UTC (permalink / raw)
To: Nazar Mokrynskyi, ath12k; +Cc: linux-wireless
In-Reply-To: <6f46ab6c-c7c0-4865-a68b-992ace4225d8@mokrynskyi.com>
On 6/29/2026 8:52 PM, Nazar Mokrynskyi wrote:
> Anything else I can do to help upstream some version of these patches?
> I've been running them for another 1.5 months with no issues.
It is still in my patchwork queue.
/jeff
^ permalink raw reply
* Re: [PATCH net-next 0/8] drivers/net: replace __get_free_pages() with kmalloc()
From: Mike Rapoport @ 2026-06-30 14:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Brian Norris, Edward Cree, Francesco Dolcini, Manish Chopra,
Przemek Kitszel, Sudarsana Kalluru, Tony Nguyen, b43-dev,
intel-wired-lan, libertas-dev, linux-kernel, linux-mm,
linux-net-drivers, linux-wireless, netdev
In-Reply-To: <20260630072344.159b5d99@kernel.org>
On Tue, Jun 30, 2026 at 07:23:44AM -0700, Jakub Kicinski wrote:
> On Tue, 30 Jun 2026 13:59:19 +0300 Mike Rapoport (Microsoft) wrote:
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 6 +--
> > drivers/net/ethernet/intel/ice/ice_gnss.c | 5 +-
> > drivers/net/ethernet/sfc/mcdi.c | 7 +--
> > drivers/net/ethernet/sfc/siena/mcdi.c | 7 +--
> > drivers/net/wireless/broadcom/b43/debugfs.c | 12 ++---
> > drivers/net/wireless/broadcom/b43legacy/debugfs.c | 11 ++--
> > drivers/net/wireless/marvell/libertas/debugfs.c | 39 ++++++--------
> > drivers/net/wireless/marvell/mwifiex/debugfs.c | 62 ++++++++++-------------
> > drivers/net/wireless/ti/wlcore/main.c | 14 +++--
>
> You gotta split this, wireless and ethernet go via separate trees.
Sure.
> BTW cocci also suggests folding in a memset, IDK if it's worth it.
Same churn, less lines :)
> drivers/net/wireless/broadcom/b43legacy/debugfs.c:217:8-15: WARNING: kzalloc should be used for buf, instead of kmalloc/memset
> --
> pw-bot: cr
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH net-next 0/8] drivers/net: replace __get_free_pages() with kmalloc()
From: Jakub Kicinski @ 2026-06-30 14:23 UTC (permalink / raw)
To: Mike Rapoport (Microsoft)
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Brian Norris, Edward Cree, Francesco Dolcini, Manish Chopra,
Przemek Kitszel, Sudarsana Kalluru, Tony Nguyen, b43-dev,
intel-wired-lan, libertas-dev, linux-kernel, linux-mm,
linux-net-drivers, linux-wireless, netdev
In-Reply-To: <20260630-b4-drivers-net-v1-0-672162a91f37@kernel.org>
On Tue, 30 Jun 2026 13:59:19 +0300 Mike Rapoport (Microsoft) wrote:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 6 +--
> drivers/net/ethernet/intel/ice/ice_gnss.c | 5 +-
> drivers/net/ethernet/sfc/mcdi.c | 7 +--
> drivers/net/ethernet/sfc/siena/mcdi.c | 7 +--
> drivers/net/wireless/broadcom/b43/debugfs.c | 12 ++---
> drivers/net/wireless/broadcom/b43legacy/debugfs.c | 11 ++--
> drivers/net/wireless/marvell/libertas/debugfs.c | 39 ++++++--------
> drivers/net/wireless/marvell/mwifiex/debugfs.c | 62 ++++++++++-------------
> drivers/net/wireless/ti/wlcore/main.c | 14 +++--
You gotta split this, wireless and ethernet go via separate trees.
BTW cocci also suggests folding in a memset, IDK if it's worth it.
drivers/net/wireless/broadcom/b43legacy/debugfs.c:217:8-15: WARNING: kzalloc should be used for buf, instead of kmalloc/memset
--
pw-bot: cr
^ permalink raw reply
* [PATCH rtw-next v4 3/3] wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
From: William Hansen-Baird @ 2026-06-30 14:15 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260630141553.785769-1-william.hansen.baird@gmail.com>
RTL8723BE outputs a large amount of PCIe AER errors during and
after boot, even before probe and when driver is never loaded.
This causes significant system slowdown.
The errors are the same as reported by
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
Add the RTL8723BE with subsystem ID 17aa:b736 to the rtl_aspm_quirks
table to stop the AER errors. AER errors can still be present prior to
pci probe, as the device by default may have ASPM enabled.
Testing on a Razer Blade 14 2017 which shipped from the
OEM equipped with an RTL8723BE card with this subsystem ID
confirms that this patch resolves the AER flood and allows the
wireless card to function normally once the driver takes over.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 9a9c895b0bef..220fb4dc7927 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -34,6 +34,8 @@ static const u8 ac_to_hwq[] = {
static const struct pci_device_id rtl_aspm_quirks[] = {
/* ASUSTek F441U/X555UQ */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ /* Razer Blade 14 2017 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x17aa, 0xb736) },
{}
};
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v4 2/3] wifi: rtlwifi: convert pci if-statement to ID table
From: William Hansen-Baird @ 2026-06-30 14:15 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260630141553.785769-1-william.hansen.baird@gmail.com>
Refactor the ASUSTek quirk logic from an if-statement to a standard
rtl_aspm_quirks pci_device_id table. This allows future devices with
the same quirk to be added more easily while avoiding a large if-chain.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index f706575f92ce..9a9c895b0bef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -31,6 +31,12 @@ static const u8 ac_to_hwq[] = {
BK_QUEUE
};
+static const struct pci_device_id rtl_aspm_quirks[] = {
+ /* ASUSTek F441U/X555UQ */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_REALTEK, 0xb723, 0x11ad, 0x1723) },
+ {}
+};
+
static u8 _rtl_mac_to_hwqueue(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
@@ -330,19 +336,15 @@ static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
- struct rtl_priv *rtlpriv = rtl_priv(hw);
_rtl_pci_update_default_setting(hw);
/*
- * RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
+ * Certain pci devices are known to output large
* amounts of PCIe AER errors during and after boot up, causing
* heavy lags, poor network throughput, and occasional lock-ups.
*/
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723)) {
+ if (pci_match_id(rtl_aspm_quirks, rtlpci->pdev)) {
__rtl_pci_disable_aspm(hw);
ppsc->support_aspm = false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v4 1/3] wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
From: William Hansen-Baird @ 2026-06-30 14:15 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260630141553.785769-1-william.hansen.baird@gmail.com>
commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
adds code which sets ppsc->support_aspm to false in
_rtl_pci_update_default_setting() in order to disable ASPM.
This does not, however, disable ASPM. Rather, it disables driver
control of ASPM, and blocks calls to rtl_pci_enable_aspm()
and rtl_pci_disable_aspm().
In some cases, the pci device supplied to the probe function has
ASPM enabled. The code would therefore not disable ASPM, as it means to,
but rather just leave it enabled.
This was discovered through testing on a Razer Blade 14 2017.
Implement a new __rtl_pci_disable_aspm(hw) function which does not check
ppsc->support_aspm before disabling and call it from
rtl_pci_disable_aspm().
Then move the code added in the previous commit to rtl_pci_init_aspm() to
allow adding a call to __rtl_pci_disable_aspm(hw).
This makes sure ASPM is disabled while still disabling
driver control of ASPM to block it from being enabled later.
Signed-off-by: William Hansen-Baird <william.hansen.baird@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 39 ++++++++++++++--------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 73018a0498b4..f706575f92ce 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -156,15 +156,6 @@ static void _rtl_pci_update_default_setting(struct ieee80211_hw *hw)
PCI_EXP_LNKCTL_ASPM_L1 | PCI_EXP_LNKCTL_CCC))
ppsc->support_aspm = false;
- /* RTL8723BE found on some ASUSTek laptops, such as F441U and
- * X555UQ with subsystem ID 11ad:1723 are known to output large
- * amounts of PCIe AER errors during and after boot up, causing
- * heavy lags, poor network throughput, and occasional lock-ups.
- */
- if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
- (rtlpci->pdev->subsystem_vendor == 0x11ad &&
- rtlpci->pdev->subsystem_device == 0x1723))
- ppsc->support_aspm = false;
}
static bool _rtl_pci_platform_switch_device_pci_aspm(
@@ -203,7 +194,7 @@ static void _rtl_pci_switch_clk_req(struct ieee80211_hw *hw, u16 value)
}
/*Disable RTL8192SE ASPM & Disable Pci Bridge ASPM*/
-static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+static void __rtl_pci_disable_aspm(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
@@ -215,9 +206,6 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
u16 aspmlevel = 0;
u16 tmp_u1b = 0;
- if (!ppsc->support_aspm)
- return;
-
if (pcibridge_vendor == PCI_BRIDGE_VENDOR_UNKNOWN) {
rtl_dbg(rtlpriv, COMP_POWER, DBG_TRACE,
"PCI(Bridge) UNKNOWN\n");
@@ -240,6 +228,16 @@ static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
_rtl_pci_platform_switch_device_pci_aspm(hw, linkctrl_reg);
}
+static void rtl_pci_disable_aspm(struct ieee80211_hw *hw)
+{
+ struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+
+ if (!ppsc->support_aspm)
+ return;
+
+ __rtl_pci_disable_aspm(hw);
+}
+
/*Enable RTL8192SE ASPM & Enable Pci Bridge ASPM for
*power saving We should follow the sequence to enable
*RTL8192SE first then enable Pci Bridge ASPM
@@ -330,10 +328,25 @@ static void rtl_pci_parse_configuration(struct pci_dev *pdev,
static void rtl_pci_init_aspm(struct ieee80211_hw *hw)
{
+ struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
_rtl_pci_update_default_setting(hw);
+ /*
+ * RTL8723BE found on some ASUSTek laptops, such as F441U and
+ * X555UQ with subsystem ID 11ad:1723 are known to output large
+ * amounts of PCIe AER errors during and after boot up, causing
+ * heavy lags, poor network throughput, and occasional lock-ups.
+ */
+ if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE &&
+ (rtlpci->pdev->subsystem_vendor == 0x11ad &&
+ rtlpci->pdev->subsystem_device == 0x1723)) {
+ __rtl_pci_disable_aspm(hw);
+ ppsc->support_aspm = false;
+ }
+
if (ppsc->reg_rfps_level & RT_RF_PS_LEVEL_ALWAYS_ASPM) {
/*Always enable ASPM & Clock Req. */
rtl_pci_enable_aspm(hw);
--
2.54.0
^ permalink raw reply related
* [PATCH rtw-next v4 0/3] wifi: rtlwifi: fix ASPM AER flooding on RTL8723BE devices
From: William Hansen-Baird @ 2026-06-30 14:15 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel, William Hansen-Baird
In-Reply-To: <20260626095648.1124924-1-william.hansen.baird@gmail.com>
This series fixes AER error message flooding and system slowdown caused by
RTL8723BE with subsystem ID 17aa:b736. The flood is found to be caused
by ASPM, and disabling it stops the AER spam.
This flood of AER error messages for the RTL8723BE is not unique to
subsystem ID 17aa:b736.
Commit 77a6407c6ab2 ("wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723")
targets the same issue for subsystem ID 11ad:1723.
The fix applied in that commit, however, does not correctly
disable ASPM. It merely disables driver control of ASPM.
Patch 1 fixes the previous commit such that it properly disables ASPM for
subsystem ID 11ad:1723.
Patch 2 converts the if-statement check of subsystem IDs to a
rtl_aspm_quirks pci_device_id table matched with pci_match_id()
such that future devices can easily be added if they have the same error.
Patch 3 adds the RTL8723BE with subsystem ID 17aa:b736 to the
rtl_aspm_quirks table to disable ASPM for it. Testing on a
Razer Blade 14 2017 showed this stops the AER error message flood and
wifi works as it should.
---
v4:
- Patch 1: remove trailing whitespace
- Patch 2: remove space from {} in rtl_aspm_quirks table
- Carry forward Acked-by from v3 for Patch 1 and 2
v3:
- Replace { 0 } with { } in rtl_pci_quirks table as recommended by Uwe
and requested by Ping-Ke
- Added comments to rtl_pci_quirks table describing what machine
correspond to the pci ids
- Replace net-specific comment style with wireless comment style
- Removed misleading Fixes tag from patch 1.
- Patch 3: carried forward Acked-by from v2
v2:
- Implement __rtl_pci_disable_aspm() in patch 1 which disables ASPM
without checking ppsc->support_aspm.
This is called both by rtl_pci_disable_aspm(), guarded by the original
check of ppsc->support_aspm, and the new quirk code.
- Rename rtl8723be_aspm_quirks to rtl_aspm_quirks and fill out system
vendor and device ID alongside subsystem vendor and device ID in the
rtl_aspm_quirks table such that we can use pci_match_id() alone
without the RTL8723BE check.
William Hansen-Baird (3):
wifi: rtlwifi: fix disabling of ASPM for RTL8723BE with AER flooding
wifi: rtlwifi: convert pci if-statement to ID table
wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 17aa:b736
drivers/net/wireless/realtek/rtlwifi/pci.c | 43 +++++++++++++++-------
1 file changed, 30 insertions(+), 13 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 0/4] usb: fix UAF related to dynamic ID
From: Danilo Krummrich @ 2026-06-30 13:39 UTC (permalink / raw)
To: Manuel Ebner
Cc: Gary Guo, Greg Kroah-Hartman, Rafael J. Wysocki,
Toke Høiland-Jørgensen, Johan Hovold, linux-wireless,
linux-kernel, linux-usb, driver-core
In-Reply-To: <6d1b5937df1fe002c47b226640f57fda2c0ee862.camel@mailbox.org>
Hi Manuel,
On Tue Jun 30, 2026 at 3:26 PM CEST, Manuel Ebner wrote:
> On Tue, 2026-06-30 at 12:38 +0100, Gary Guo wrote:
>> [...]
>>
>> Signed-off-by: Gary Guo <gary@garyguo.net>
>
> For all four patches:
> LGTM.
>
> I guess I'm not in a position to Acked-by or Reviewed-by.
I don't know your background and I don't want to make any assumptions, so please
don't interpret anything in my attempt to clarify a bit.
As documented in [1] "any interested reviewer (who has done the work and is a
person with known identity) can offer a Reviewed-by tag for a patch".
An offer from anyone who has done this work is much appreciated.
Acked-by is usually used by stakeholders of the code (most commonly maintainers)
to indicate acceptance, e.g. for patch routing purposes. There are more details
in [2].
[1] https://docs.kernel.org/process/submitting-patches.html#reviewer-s-statement-of-oversight
[2] https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: wireless: ath12k: drop qcom,ath12k-calibration-variant
From: Andrew LaMarche @ 2026-06-30 13:30 UTC (permalink / raw)
To: Johannes Berg, Jeff Johnson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-wireless, devicetree, ath12k, linux-kernel, Andrew LaMarche,
Ernest Van Hoecke
In-Reply-To: <20260630133001.1426824-1-andrewjlamarche@gmail.com>
The ath12k-wsi binding documentation describes using the
generation-specific qcom,ath12k-calibration-variant binding as well as
the generation-agnostic qcom,calibration-variant binding to load
board-specific calibration data from the device tree. However, the
driver never implemented either of these.
Given that no devices currently supported use
qcom,ath12k-calibration-variant and the previous patch implements
qcom,calibration-variant, drop the generation-specific version from the
binding to prevent future confusion.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
---
.../devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml | 7 -------
1 file changed, 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
index 589960144fe1..fa64c8aa56f5 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml
@@ -58,13 +58,6 @@ properties:
String to uniquely identify variant of the calibration data for designs
with colliding bus and device ids
- qcom,ath12k-calibration-variant:
- $ref: /schemas/types.yaml#/definitions/string
- deprecated: true
- description:
- String to uniquely identify variant of the calibration data for designs
- with colliding bus and device ids
-
qcom,wsi-controller:
$ref: /schemas/types.yaml#/definitions/flag
description:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] wifi: ath12k: support calibration-variant from device tree
From: Andrew LaMarche @ 2026-06-30 13:30 UTC (permalink / raw)
To: Johannes Berg, Jeff Johnson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-wireless, devicetree, ath12k, linux-kernel, Andrew LaMarche,
Ernest Van Hoecke
ath10k and ath11k support reading calibration variants from the device
tree to locate the correct Board Description File (BDF). The ath12k-wsi
binding already describes using qcom,calibration-variant but it is not
implemented in the driver.
Many ath12k designs expose all the radios under a single phy, each of
which typically require a separate BDF. Without this, the radios may not
come up or will not be calibrated correctly.
Fix this by parsing the device tree for the generation-agnostic
qcom,calibration-variant. This allows the driver to properly select,
read and apply the correct BDF.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
---
Changes in v2:
- Drop ath12k-specific binding qcom,ath12k-calibration-variant in favor
of generation agnostic qcom,calibration-variant.
- Link to v1: https://lore.kernel.org/all/20260131003222.2011259-1-andrewjlamarche@gmail.com
---
drivers/net/wireless/ath/ath12k/core.c | 22 ++++++++++++++++++++++
drivers/net/wireless/ath/ath12k/qmi.c | 4 ++++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 742d4fd1b598..52c28864c63c 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -812,6 +812,28 @@ int ath12k_core_check_smbios(struct ath12k_base *ab)
return 0;
}
+int ath12k_core_check_dt(struct ath12k_base *ab)
+{
+ size_t max_len = sizeof(ab->qmi.target.bdf_ext);
+ const char *variant = NULL;
+ struct device_node *node;
+
+ node = ab->dev->of_node;
+ if (!node)
+ return -ENOENT;
+
+ of_property_read_string(node, "qcom,calibration-variant",
+ &variant);
+ if (!variant)
+ return -ENODATA;
+
+ if (strscpy(ab->qmi.target.bdf_ext, variant, max_len) < 0)
+ ath12k_dbg(ab, ATH12K_DBG_BOOT,
+ "bdf variant string is longer than the buffer can accommodate (variant: %s)\n", variant);
+
+ return 0;
+}
+
static int ath12k_core_soc_create(struct ath12k_base *ab)
{
int ret;
diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
index fd762b5d7bb5..3cf39ae06fd3 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.c
+++ b/drivers/net/wireless/ath/ath12k/qmi.c
@@ -2945,6 +2945,10 @@ int ath12k_qmi_request_target_cap(struct ath12k_base *ab)
if (r)
ath12k_dbg(ab, ATH12K_DBG_QMI, "SMBIOS bdf variant name not set.\n");
+ r = ath12k_core_check_dt(ab);
+ if (r)
+ ath12k_dbg(ab, ATH12K_DBG_QMI, "DT bdf variant name not set.\n");
+
r = ath12k_acpi_start(ab);
if (r)
/* ACPI is optional so continue in case of an error */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/4] usb: fix UAF related to dynamic ID
From: Manuel Ebner @ 2026-06-30 13:26 UTC (permalink / raw)
To: Gary Guo, Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Toke Høiland-Jørgensen, Johan Hovold
Cc: linux-wireless, linux-kernel, linux-usb, driver-core
In-Reply-To: <20260630-usb_dyn_id_uaf-v1-0-160a02be5ac2@garyguo.net>
On Tue, 2026-06-30 at 12:38 +0100, Gary Guo wrote:
> [...]
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
For all four patches:
LGTM.
I guess I'm not in a position to Acked-by or Reviewed-by.
Manuel
> ---
> Gary Guo (4):
> wifi: ath9k_htc: don't keep usb_device_id
> usb: usbtmc: don't keep usb_device_id
> usb: serial: spcp8x5: don't keep usb_device_id
> usb: fix UAF when probe runs concurrent to dyn ID removal
>
> drivers/net/wireless/ath/ath9k/hif_usb.c | 12 ++++++------
> drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +-
> drivers/usb/class/usbtmc.c | 2 --
> drivers/usb/core/driver.c | 33 ++++++++++++++++----------------
> drivers/usb/serial/spcp8x5.c | 6 +++---
> include/linux/usb.h | 3 ++-
> 6 files changed, 29 insertions(+), 29 deletions(-)
> ---
> base-commit: 7de6ae9e12207ec146f2f3f1e58d1a99317e88bc
> change-id: 20260629-usb_dyn_id_uaf-9d5f415387d4
>
> Best regards,
> --
> Gary Guo <gary@garyguo.net>
^ permalink raw reply
* Re: [PATCH v8 13/14] firmware: qcom_scm: Remove SCM PAS wrappers
From: Konrad Dybcio @ 2026-06-30 12:45 UTC (permalink / raw)
To: Sumit Garg, andersson
Cc: linux-arm-msm, dri-devel, freedreno, linux-media, netdev,
linux-wireless, ath12k, linux-remoteproc, konradybcio, robh,
krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260626133440.692849-14-sumit.garg@kernel.org>
On 6/26/26 3:34 PM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Now since all the Qcom SCM client drivers have been migrated over to
> generic PAS TZ service, let's drop the exported SCM PAS wrappers.
>
> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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