* [PATCH 3/3] [v5 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Arnd Bergmann @ 2026-05-07 21:24 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20260507212451.3333185-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Converted from the platform_device creation in board-n8x0.c.
Link: https://lore.kernel.org/all/20230314163201.955689-1-arnd@kernel.org/
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/ti/omap/omap2.dtsi | 4 ++++
arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi | 12 ++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/omap2.dtsi b/arch/arm/boot/dts/ti/omap/omap2.dtsi
index afabb36a8ac1..fdc1790adf43 100644
--- a/arch/arm/boot/dts/ti/omap/omap2.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2.dtsi
@@ -129,6 +129,8 @@ i2c2: i2c@48072000 {
};
mcspi1: spi@48098000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi1";
reg = <0x48098000 0x100>;
@@ -140,6 +142,8 @@ mcspi1: spi@48098000 {
};
mcspi2: spi@4809a000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi2";
reg = <0x4809a000 0x100>;
diff --git a/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
index 63b0b4921e4e..fe9dd8bbfc85 100644
--- a/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
@@ -109,3 +109,15 @@ partition@5 {
};
};
};
+
+&mcspi2 {
+ status = "okay";
+
+ wifi@0 {
+ reg = <0>;
+ compatible = "st,stlc4560";
+ spi-max-frequency = <48000000>;
+ interrupts-extended = <&gpio3 23 IRQ_TYPE_EDGE_RISING>;
+ powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>; /* gpio 97 */
+ };
+};
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v3 1/3] wifi: wcn36xx: fix heap overflow from oversized firmware HAL response
From: Loic Poulain @ 2026-05-07 21:29 UTC (permalink / raw)
To: Tristan Madani; +Cc: Johannes Berg, wcn36xx, linux-wireless, Tristan Madani
In-Reply-To: <20260421135018.352774-2-tristmd@gmail.com>
On Tue, Apr 21, 2026 at 3:50 PM Tristan Madani <tristmd@gmail.com> wrote:
>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware response dispatcher copies all synchronous HAL responses
> into the 4096-byte hal_buf without validating the response length. A
> response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow
> with firmware-controlled content.
>
> Add a bounds check on the response length.
>
> Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
>
> Changes in v2:
> - No code changes from v1.
>
> drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 813553edcb789..f65328329f4f0 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -3293,6 +3293,10 @@ int wcn36xx_smd_rsp_process(struct rpmsg_device *rpdev,
> case WCN36XX_HAL_EXIT_IMPS_RSP:
> case WCN36XX_HAL_UPDATE_CHANNEL_LIST_RSP:
> case WCN36XX_HAL_ADD_BCN_FILTER_RSP:
> + if (len > WCN36XX_HAL_BUF_SIZE) {
> + wcn36xx_warn("HAL response too large: %d\n", len);
> + break;
> + }
> memcpy(wcn->hal_buf, buf, len);
> wcn->hal_rsp_len = len;
> complete(&wcn->hal_rsp_compl);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Fix phandle-array constraints, again
From: Rob Herring (Arm) @ 2026-05-07 21:30 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Jakub Kicinski, Eric Dumazet, Paolo Abeni, Wolfram Sang,
Andrew Lunn, linux-kernel, linux-mmc, dri-devel, devicetree,
Johannes Berg, Bjorn Andersson, Krzysztof Wilczyński,
linux-arm-kernel, Jeff Johnson, linux-pci, Lorenzo Pieralisi,
linux-usb, Conor Dooley, ath11k, linux-spi, linux-remoteproc,
Ulf Hansson, Greg Kroah-Hartman, Andi Shyti,
Manivannan Sadhasivam, David S. Miller, Mathieu Poirier,
Maxime Ripard, Sylwester Nawrocki, linux-wireless, Mark Brown,
linux-sound, linux-i2c, Bjorn Helgaas, netdev, ath10k,
Krzysztof Kozlowski
In-Reply-To: <20260507201749.2605365-1-robh@kernel.org>
On Thu, 07 May 2026 15:16:00 -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> v2:
> - Add proper descriptions for 'qcom,smem-states'. Thanks Krzysztof!
> - Fix i2c-parent warning
> - Fix extra blank lines
> ---
> .../rockchip/rockchip,rk3399-cdn-dp.yaml | 2 ++
> .../bindings/i2c/i2c-demux-pinctrl.yaml | 1 +
> .../mmc/hisilicon,hi3798cv200-dw-mshc.yaml | 7 ++++---
> .../devicetree/bindings/net/qcom,bam-dmux.yaml | 12 ++++++++++++
> .../devicetree/bindings/net/qcom,ipa.yaml | 12 ++++++++++++
> .../bindings/net/wireless/qcom,ath10k.yaml | 8 +++++++-
> .../bindings/net/wireless/qcom,ath11k.yaml | 8 +++++++-
> .../net/wireless/qcom,ipq5332-wifi.yaml | 18 ++++++++++++++++++
> .../bindings/pci/toshiba,tc9563.yaml | 5 +++--
> .../remoteproc/qcom,msm8916-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,msm8996-mss-pil.yaml | 7 +++++++
> .../bindings/remoteproc/qcom,pas-common.yaml | 6 ++++++
> .../remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7180-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-adsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-wpss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sdm845-adsp-pil.yaml | 6 ++++++
> .../bindings/remoteproc/qcom,wcnss-pil.yaml | 6 ++++++
> .../devicetree/bindings/sound/samsung,tm2.yaml | 8 ++++++--
> .../bindings/spi/st,stm32mp25-ospi.yaml | 5 +++--
> .../bindings/usb/chipidea,usb2-common.yaml | 2 ++
> .../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 ++++---
> 23 files changed, 142 insertions(+), 14 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.example.dtb: i2c-mux3 (i2c-demux-pinctrl): i2c-parent:0: [2, 3, 4] is too long
from schema $id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.example.dtb: i2c-mux3 (i2c-demux-pinctrl): i2c-parent: [[2, 3, 4]] is too short
from schema $id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260507201749.2605365-1-robh@kernel.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 3/3] wifi: wcn36xx: fix OOB read from short trigger BA firmware response
From: Loic Poulain @ 2026-05-07 21:35 UTC (permalink / raw)
To: Tristan Madani; +Cc: Johannes Berg, wcn36xx, linux-wireless, Tristan Madani
In-Reply-To: <20260421135018.352774-4-tristmd@gmail.com>
On Tue, Apr 21, 2026 at 3:50 PM Tristan Madani <tristmd@gmail.com> wrote:
>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware response length is only checked against sizeof(*rsp) (20
> bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
> at buf + 20 without verifying the response contains it. This causes an
> out-of-bounds read of stale heap data, corrupting the BA session state.
>
> Add validation that the response includes the candidate data.
>
> Fixes: 16be1ac55944 ("wcn36xx: Parse trigger_ba response properly")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
>
> Changes in v2:
> - No code changes from v1.
>
> drivers/net/wireless/ath/wcn36xx/smd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 2a0c946d81095..c0b477345832b 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -2599,6 +2599,9 @@ static int wcn36xx_smd_trigger_ba_rsp(void *buf, int len, struct add_ba_info *ba
> if (rsp->candidate_cnt < 1)
> return rsp->status ? rsp->status : -EINVAL;
>
> + if (len < sizeof(*rsp) + sizeof(*candidate))
> + return -EINVAL;
> +
> candidate = (struct wcn36xx_hal_trigger_ba_rsp_candidate *)(buf + sizeof(*rsp));
>
> for (i = 0; i < STACFG_MAX_TC; i++) {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 2/3] wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
From: Loic Poulain @ 2026-05-07 21:36 UTC (permalink / raw)
To: Tristan Madani; +Cc: Johannes Berg, wcn36xx, linux-wireless
In-Reply-To: <20260415223710.1616925-3-tristmd@gmail.com>
On Thu, Apr 16, 2026 at 12:37 AM Tristan Madani <tristmd@gmail.com> wrote:
>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware-controlled rsp->count field is used as the loop bound for
> indexing into the flexible rsp->regs[] array without validation against
> the message length. A count exceeding the actual data causes out-of-
> bounds reads from the heap-allocated message buffer.
>
> Add a check that count fits within the received message.
>
> Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/wcn36xx/smd.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index XXXXXXX..XXXXXXX 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -2803,6 +2803,12 @@ static int wcn36xx_smd_print_reg_info_ind(struct wcn36xx *wcn,
> return -EIO;
> }
>
> + if (rsp->count > (len - sizeof(*rsp)) / sizeof(rsp->regs[0])) {
> + wcn36xx_warn("Truncated print reg info indication: count %u, len %zu\n",
> + rsp->count, len);
> + return -EIO;
> + }
> +
> wcn36xx_dbg(WCN36XX_DBG_HAL,
> "reginfo indication, scenario: 0x%x reason: 0x%x\n",
> rsp->scenario, rsp->reason);
>
^ permalink raw reply
* [PATCH] wifi: cfg80211: advance loop vars in cfg80211_merge_profile()
From: John Walker @ 2026-05-07 23:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: security, John Walker, w, linux-wireless
In-Reply-To: <78faec4efa3019c6101ee0a6c329189f1ddf845b.camel@sipsolutions.net>
cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS
profile that has been split across multiple consecutive MBSSID elements.
Its while-loop calls
cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem)
but never advances mbssid_elem or sub_elem inside the body. Each
iteration therefore searches for a continuation that follows the same
fixed pair; the helper returns the same next_mbssid; and the same
next_sub bytes are memcpy()'d into merged_ie at a growing offset until
the buffer fills.
Advance both mbssid_elem and sub_elem to the just-consumed continuation
so the next call to cfg80211_get_profile_continuation() searches for a
further continuation beyond it (or returns NULL when none exists).
A specially-crafted malicious beacon can take advantage of this bug
to cause the kernel to spend an excessive amount of time in
cfg80211_merge_profile (up to as much as 2ms per beacon recieved),
which could theoretically be abused in some way.
Fixes: fe806e4992c9 ("cfg80211: support profile split between elements")
Cc: w@1wt.eu
Cc: linux-wireless@vger.kernel.org
Signed-off-by: John Walker <johnwalker0@gmail.com>
---
net/wireless/scan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 328af43ef832..358cbc9e43d8 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -2462,6 +2462,9 @@ size_t cfg80211_merge_profile(const u8 *ie, size_t ielen,
memcpy(merged_ie + copied_len, next_sub->data,
next_sub->datalen);
copied_len += next_sub->datalen;
+
+ mbssid_elem = next_mbssid;
+ sub_elem = next_sub;
}
return copied_len;
base-commit: fcee7d82f27d6a8b1ddc5bbefda59b4e441e9bc0
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [syzbot] [wireless?] WARNING in wiphy_register (5)
From: syzbot @ 2026-05-08 0:30 UTC (permalink / raw)
To: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2281958e6007 Merge tag 'wireless-next-2026-05-06' of https..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=139f656a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f2b487b72ffad035
dashboard link: https://syzkaller.appspot.com/bug?extid=2002864e6c6895cb0ac3
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=1452fb48580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=179f656a580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4df17f60254b/disk-2281958e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1e93157edd25/vmlinux-2281958e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/60dbf6a0a81c/bzImage-2281958e.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2002864e6c6895cb0ac3@syzkaller.appspotmail.com
------------[ cut here ]------------
(wiphy->interface_modes & BIT(NL80211_IFTYPE_NAN_DATA)) && (!wiphy->nan_capa.phy.ht.ht_supported || wiphy->n_radio > 1)
WARNING: net/wireless/core.c:885 at wiphy_register+0x58a/0x2fe0 net/wireless/core.c:884, CPU#0: syz.0.17/5835
Modules linked in:
CPU: 0 UID: 0 PID: 5835 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:wiphy_register+0x58a/0x2fe0 net/wireless/core.c:884
Code: 00 00 e8 49 8f d4 f6 90 0f 0b 90 e9 67 0a 00 00 e8 3b 8f d4 f6 e9 59 0a 00 00 e8 31 8f d4 f6 e9 eb 00 00 00 e8 27 8f d4 f6 90 <0f> 0b 90 e9 45 0a 00 00 44 89 f8 24 06 0f b6 d8 31 ff 89 de e8 0d
RSP: 0018:ffffc90003236860 EFLAGS: 00010293
RAX: ffffffff8af13fe2 RBX: 0000000000000004 RCX: ffff88802ed60000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001
RBP: ffffc900032369f0 R08: ffff8880582b0faf R09: 1ffff1100b0561f5
R10: dffffc0000000000 R11: ffffed100b0561f6 R12: ffff8880582b0740
R13: dffffc0000000000 R14: ffffffff8d002990 R15: ffff8880582b0804
FS: 0000555593855500(0000) GS:ffff888125289000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007eff2e872700 CR3: 0000000075672000 CR4: 00000000003526f0
Call Trace:
<TASK>
ieee80211_register_hw+0x3c53/0x4910 net/mac80211/main.c:1627
mac80211_hwsim_new_radio+0x3327/0x57e0 drivers/net/wireless/virtual/mac80211_hwsim_main.c:6047
hwsim_new_radio_nl+0xe20/0x26e0 drivers/net/wireless/virtual/mac80211_hwsim_main.c:6832
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x61c/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2551
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1895
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2698
___sys_sendmsg+0x2a5/0x360 net/socket.c:2752
__sys_sendmsg net/socket.c:2784 [inline]
__do_sys_sendmsg net/socket.c:2789 [inline]
__se_sys_sendmsg net/socket.c:2787 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2787
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7eff2e99cdd9
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:00007ffd72c5edf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007eff2ec15fa0 RCX: 00007eff2e99cdd9
RDX: 0000000000000000 RSI: 0000200000000100 RDI: 0000000000000003
RBP: 00007eff2ea32d69 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007eff2ec15fac R14: 00007eff2ec15fa0 R15: 00007eff2ec15fa0
</TASK>
---
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: [PATCH v2] wifi: rtw88: remove rtw_txq_dequeue
From: Ping-Ke Shih @ 2026-05-08 0:56 UTC (permalink / raw)
To: Martin Kaiser
Cc: Bitterblue Smith, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260507082238.889656-1-martin@kaiser.cx>
Martin Kaiser <martin@kaiser.cx> wrote:
> Remove the rtw_txq_dequeue helper. It's a wrapper around
> ieee80211_tx_dequeue with just one caller.
>
> Call ieee80211_tx_dequeue directly in rtw_txq_push. There's no need to
> fetch txq for every frame, we can do this once outside of the rcu lock.
>
> Make the loop variable i unsigned long, it should have the same type as
> frames.
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
^ permalink raw reply
* RE: [PATCH v2] wifi: rtw88: increase TX report timeout to fix race condition
From: Ping-Ke Shih @ 2026-05-08 3:12 UTC (permalink / raw)
To: luka.gejak@linux.dev, Kalle Valo
Cc: Stanislaw Gruszka, Yan-Hsuan Chuang, Brian Norris,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20260507163621.73295-1-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> The driver expects the firmware to report TX status within 500ms.
> However, a timeout can be triggered when the hardware performs
> background scans while under TX load. During these scans, the firmware
> stays off-channel for periods exceeding 500ms, delaying the delivery of
> TX reports back to the driver.
>
> When this occurs, the purge timer fires prematurely and drops the
> tracking skbs from the queue. This results in the host stack
> interpreting the missing status as packet loss, leading to TCP window
> collapse. In testing with iperf3, this causes throughput to drop from
> ~90 Mbps to near-zero for approximately 2 seconds until the connection
> recovers.
>
> Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
> sufficient to accommodate off-channel dwell time during full background
> scans, ensuring the purge timer only trips during genuine firmware
> lockups and preventing unnecessary TCP retransmission cycles.
>
> Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
I don't think this commit introduce USB support.
> Cc: stable@vger.kernel.org
> Tested-by: Luka Gejak <luka.gejak@linux.dev>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> Changes in v2:
> -Isolated the change to RTL8723DU as requested by Ping-Ke
>
> drivers/net/wireless/realtek/rtw88/tx.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> index 3106edb84fb4..7fab83c3f6b5 100644
> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> @@ -196,6 +196,7 @@ void rtw_tx_report_purge_timer(struct timer_list *t)
> void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn)
> {
> struct rtw_tx_report *tx_report = &rtwdev->tx_report;
> + unsigned long timeout;
Declare RTW_TX_PROBE_TIMEOUT as default value.
unsigned long timeout = RTW_TX_PROBE_TIMEOUT;
> unsigned long flags;
> u8 *drv_data;
>
> @@ -207,7 +208,13 @@ void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn)
> __skb_queue_tail(&tx_report->queue, skb);
> spin_unlock_irqrestore(&tx_report->q_lock, flags);
>
> - mod_timer(&tx_report->purge_timer, jiffies + RTW_TX_PROBE_TIMEOUT);
> + if (rtwdev->chip->id == RTW_CHIP_TYPE_8723D &&
> + rtwdev->hci.type == RTW_HCI_TYPE_USB)
> + timeout = msecs_to_jiffies(2500);
Only RTL8723DU uses different setting treated as an exception by if-condition.
> + else
> + timeout = RTW_TX_PROBE_TIMEOUT;
> +
> + mod_timer(&tx_report->purge_timer, jiffies + timeout);
> }
> EXPORT_SYMBOL(rtw_tx_report_enqueue);
>
> --
> 2.54.0
^ permalink raw reply
* RE: [PATCH v2] wifi: rtw88: usb: fix memory leaks on USB write failures
From: Ping-Ke Shih @ 2026-05-08 3:47 UTC (permalink / raw)
To: luka.gejak@linux.dev, Kalle Valo
Cc: Sascha Hauer, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260507163709.73581-1-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> When rtw_usb_write_port() fails to submit a USB Request Block (URB)
> (e.g., due to device disconnect or ENOMEM), the completion callback is
> never executed.
>
> Currently, the driver ignores the return value of rtw_usb_write_port()
> in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
> functions rely on the completion callback to free the socket buffers
> (skbs) and the transaction control block (txcb), a submission failure
> results in:
> 1. A memory leak of the allocated skb in rtw_usb_write_data().
> 2. A memory leak of the txcb structure and all aggregated skbs in
> rtw_usb_tx_agg_skb().
>
> Fix this by checking the return value of rtw_usb_write_port(). If it
> fails, explicitly free the skb in rtw_usb_write_data(), and properly
> purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
>
> The issue was discovered in practice during device disconnect/reconnect
> scenarios and memory pressure conditions. Tested by verifying normal TX
> operation continues after the fix without regressions.
Did the memory pressure condition happen? and falls into the cases you are
adding? This is main thing I want to know.
>
> Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support")
I don't find this commit touching the code related to this patch.
> Cc: stable@vger.kernel.org
> Tested-by: Luka Gejak <luka.gejak@linux.dev>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> Changes in v2:
> - Use ret = rtw_usb_write_port(...); style, and check by next line (in
> rtw_usb_tx_agg_skb)
> - Remove unnecessary comment
> - Use ieee80211_purge_tx_queue() instead of skb_queue_purge()
If it falls into the case, you will see some warnings without this change.
Again, I'd like to know if OOM can happen in your test? If not, the test
you are doing will prove nothing, since your changes are executed only if OOM.
> - Add testing details to commit message
>
^ permalink raw reply
* RE: [PATCH v2] wifi: rtw88: usb: fix memory leaks on USB write failures
From: Luka Gejak @ 2026-05-08 4:33 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo
Cc: Sascha Hauer, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org, luka.gejak
In-Reply-To: <25a127932474456f862b0a20f7c60b65@realtek.com>
On May 8, 2026 5:47:55 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:
>luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
>> From: Luka Gejak <luka.gejak@linux.dev>
>>
>> When rtw_usb_write_port() fails to submit a USB Request Block (URB)
>> (e.g., due to device disconnect or ENOMEM), the completion callback is
>> never executed.
>>
>> Currently, the driver ignores the return value of rtw_usb_write_port()
>> in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
>> functions rely on the completion callback to free the socket buffers
>> (skbs) and the transaction control block (txcb), a submission failure
>> results in:
>> 1. A memory leak of the allocated skb in rtw_usb_write_data().
>> 2. A memory leak of the txcb structure and all aggregated skbs in
>> rtw_usb_tx_agg_skb().
>>
>> Fix this by checking the return value of rtw_usb_write_port(). If it
>> fails, explicitly free the skb in rtw_usb_write_data(), and properly
>> purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
>>
>> The issue was discovered in practice during device disconnect/reconnect
>> scenarios and memory pressure conditions. Tested by verifying normal TX
>> operation continues after the fix without regressions.
>
>Did the memory pressure condition happen? and falls into the cases you are
>adding? This is main thing I want to know.
>
>>
>> Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support")
>
>I don't find this commit touching the code related to this patch.
>
>> Cc: stable@vger.kernel.org
>> Tested-by: Luka Gejak <luka.gejak@linux.dev>
>> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
>> ---
>> Changes in v2:
>> - Use ret = rtw_usb_write_port(...); style, and check by next line (in
>> rtw_usb_tx_agg_skb)
>> - Remove unnecessary comment
>> - Use ieee80211_purge_tx_queue() instead of skb_queue_purge()
>
>If it falls into the case, you will see some warnings without this change.
>
>Again, I'd like to know if OOM can happen in your test? If not, the test
>you are doing will prove nothing, since your changes are executed only if OOM.
>
>> - Add testing details to commit message
>>
>
While triggering a genuine OOM condition (-ENOMEM) during
usb_submit_urb is admittedly difficult to force and rare in standard
environments, my testing primarily relied on device disconnects.
When a USB adapter is abruptly unplugged, rtw_usb_write_port()
naturally fails to submit the URB
(returning -ENODEV, -ESHUTDOWN, etc.). When this happens, the USB
subsystem never executes the completion callback
(rtw_usb_write_port_tx_complete or rtw_usb_write_port_complete).
Because the original code ignored the return value of
rtw_usb_write_port(), it leaked the skb and txcb structures every time
a write was attempted immediately following a disconnect. Checking the
return value catches this exact submission failure and frees the
structures on the spot.
And should I use commit that introduced USB support for Fixes tag?
Best regards,
Luka Gejak
^ permalink raw reply
* Re: [PATCH v3 1/3] lib/string_choices: Add str_alloc_free() helper
From: Greg KH @ 2026-05-08 5:18 UTC (permalink / raw)
To: Jiazi Li
Cc: Kees Cook, Andy Shevchenko, Ping-Ke Shih, Julia Lawall,
Nicolas Palix, linux-hardening, linux-wireless, mingzhu.wang
In-Reply-To: <9663db399276de3ce91a77b8a8be8220132e74a8.1778051552.git.jqqlijiazi@gmail.com>
On Thu, May 07, 2026 at 07:03:22PM +0800, Jiazi Li wrote:
> Add str_alloc_free() helper to return "alloc" or "free"
> string literal depending on the boolean argument. Also add the
> inversed variant str_free_alloc().
>
> Tested-by: mingzhu.wang <mingzhu.wang@transsion.com>
Needs a name, not an email alias.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Lucid Duck @ 2026-05-08 5:44 UTC (permalink / raw)
To: linux-wireless
Cc: Ping-Ke Shih, Bitterblue Smith, linux-kernel, Devin Wittmayer
From: Devin Wittmayer <lucid_duck@justthetip.ca>
This patch adds USB 2 to USB 3 mode switching for the AX-generation
chips in the rtw89 USB driver (8852AU, 8852BU, 8852CU and helper
variants). Without it, those adapters enumerate at USB 2.0
high-speed on first plug and stay there, capping real-world
throughput around 260 Mbps TCP regardless of radio capability.
It is Bitterblue Smith's morrownr/rtw89 commit cd287ccf544b
(2025-07-16) rebased onto wireless-next without code changes:
author's Signed-off-by preserved, my Signed-off-by added as
relayer, Tested-by per chip based on the matrix below.
The bug
=======
These chips present as USB 2 devices on first plug. The driver is
expected to send a switch-mode register write to make them disappear
and re-enumerate as USB 3 SuperSpeed. Mainline rtw89 does not issue
these commands anywhere. Every user with one of these adapters on
a mainline-derived distribution sits at the USB 2.0 ceiling for
the life of the plug, regardless of negotiated radio rate.
The fix
=======
The patch covers AX-generation chips (8852AU, 8852BU, 8852CU and
helper variants) via R_AX_PAD_CTRL2. It also adds the
switch_usb_mode module parameter (default on) for users who
experience 2.4 GHz interference under USB 3.
Mainline precedent
==================
The same mechanism is in mainline rtw88 across three commits
between July 2024 and April 2025, all authored by Bitterblue Smith:
commit 315c23a64e99 ("wifi: rtw88: usb: Support USB 3 with RTL8822CU/RTL8822BU")
commit 82a35723a67c ("wifi: rtw88: usb: Support USB 3 with RTL8812AU")
commit bf1103654df9 ("wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3")
Reviewer of record: Ping-Ke Shih, current rtw89 maintainer.
Test results
============
60 plug-cycles + 30+ gated throughput cells captured 2026-04-11
to 2026-05-07. Both x86_64 (Tiger Lake xHCI) and aarch64
(Broadcom RP1 xHCI) reproductions confirm the bug and the fix.
Hosts: Framework 13 (x86_64, Fedora 43 / 6.19.13, Tiger Lake xHCI)
NucBox K8 Plus (x86_64, Arch Linux / 6.17.9, AMD F19h USB)
Raspberry Pi 5 (aarch64, Pi OS / 6.12.47, BCM2712 + RP1)
Banana Pi BPi-R4 Pro (aarch64, OpenWrt / 6.6.93, MT7988A;
also used as a controlled lab AP)
Adapters: D-Link DWA-X1850 A1 / B1 (RTL8852AU)
BrosTrend AX1L compact / AX4L high-gain (RTL8852BU)
BrosTrend AX8L AXE5400 / EDUP AXE5400 (RTL8852CU)
APs: consumer multi-band router (WPA3-SAE / WPA2-PSK)
BPi-R4 Pro single-band lab AP (WPA3-SAE)
Server: Linux iperf3 host on 2.5 GbE wired Ethernet
Full per-cell evidence (raw iperf3 stdout, dmesg captures, sysfs
snapshots, iw link snapshots, byte-counter deltas, per-host detail)
at https://github.com/Lucid-Duck/rtw89-usb3-gap.
Plug-cycle. N=10 cycles per (chip, host) cell. Pass = post-plug
/sys/bus/usb/devices/<id>/speed reads 5000 (USB 3 SuperSpeed),
zero WARN/BUG/Oops in cycle-bracketed dmesg, non-empty association
BSSID after settle.
Adapter (chip) FW13 6.19 K8 Plus 6.17
--------------------------- ------------- --------------
DWA-X1850 A1 (RTL8852AU) 10/10 PASS 10/10 PASS
BrosTrend AX1L (RTL8852BU) 10/10 PASS 10/10 PASS
FW13: Fedora 43, 6.19.13, wireless-next + this patch
K8 Plus: Arch Linux, 6.17.9-arch1-1, morrownr/rtw89 (upstream
fork; identical AX-gen behavior to this patch)
Throughput. TCP iperf3, N=10 30-second iterations per sub-cell,
four sub-cells per cell (P=8 and P=1, each direction), to a Linux
2.5 GbE host. Per-cell /32 host route forces traffic onto the WiFi
adapter; per-iteration byte-counter cross-check on every cited cell
shows wireless tx/rx delta at 103-108% of iperf3 reported bytes
(excess is normal TCP/IP framing), so wired-NIC bleed is ruled out.
Linux tuning applied (rmem 32 MB, RPS=ff on the WiFi RX queue).
FW13 stock (in-kernel rtw89, USB 2 stuck) vs patched (USB 3
SuperSpeed), same adapter / AP / kernel / capture script, P=8 mean
Mbps, AP is the consumer multi-band router:
Adapter (chip) Band, width UL stock UL patched DL stock DL patched
-------------------------- --------------- -------- ---------- -------- ----------
EDUP AXE5400 (RTL8852CU) 6 GHz, 160 MHz 269 1364 327 579
AX8L AXE5400 (RTL8852CU) 6 GHz, 160 MHz 269 1440 324 510
AX4L AX1800 (RTL8852BU) 5 GHz, 80 MHz 208 597 293 695
AX1L AX1800 (RTL8852BU) 5 GHz, 80 MHz 235 608 273 843
DWA-X1850 A1 (RTL8852AU) 5 GHz, 80 MHz 254 748 264 707
DWA-X1850 B1 (RTL8852AU) 5 GHz, 80 MHz 248 706 265 679
USB enumeration verified at SuperSpeed (5000 Mbps) on every
patched cell, both pre and post.
K8 Plus second-rig spot check, kernel 6.17.9-arch1-1, consumer
multi-band router, single-link 5 GHz 80 MHz, TCP P=1, N=10:
DWA-X1850 A1 (RTL8852AU) 788 UL / 693 DL Mbps (sigma 16 / 54)
For comparison, every stock cell above caps at 208-327 Mbps, the
USB 2.0 ceiling.
Future work: BE-generation (RTL8922AU) USB switch-mode
======================================================
The same mechanism applies to BE-generation chips (RTL8922AU) via
R_BE_PAD_CTRL2.
The implementation is in morrownr/rtw89 commit c8a8ac49996b
("wifi: rtw89: usb: USB 3 switching for RTL8922AU", 2025-08-07)
by Bitterblue Smith, but that commit has no Signed-off-by; the
public two-week notice in
https://github.com/morrownr/rtw89/issues/82 (2026-04-21,
deadline 2026-05-05) did not produce one. checkpatch --strict
rejects third-party submission on the missing trailer.
I tested c8a8ac49996b on a BrosTrend BE6500 (RTL8922AU): plug-
cycle 10/10 PASS on both FW13 and K8 Plus; consumer-router MLO
3-link 1430 UL / 995 DL Mbps P=8; BPi-R4 Pro single-link 5 GHz
160 MHz EHT 1335 UL / 1058 DL Mbps P=8; switch_usb_mode=N forces
USB 2 at 255 UL / 311 DL Mbps. Detail in the rtw89-usb3-gap repo
above.
Adding the BE-gen switch-mode to mainline today cannot yet help
RTL8922AU users on its own, because mainline rtw89 has no
in-kernel rtw89_8922au USB driver: RTL8922AU adapters do not
attach to mainline at all. Switch-mode becomes load-bearing for
BE-gen the moment the rtw89_8922au USB driver lands upstream;
until then it would sit as dormant code. The path upstream for
the switch-mode itself is either Bitterblue's Signed-off-by on
c8a8ac49996b, or a Realtek developer carrying it as part of the
broader 8922au USB enablement.
(The AX-gen gap that this patch fixes does affect every mainline
user with an RTL8852AU/BU/CU adapter today. BE-gen is a separate,
strictly forward-looking concern.)
Submission notes
================
Applies cleanly on wireless-next HEAD 7baf5857e15d.
checkpatch.pl --strict: zero errors, zero warnings, zero checks.
Bitterblue Smith (1):
wifi: rtw89: usb: Support switching to USB 3 mode
drivers/net/wireless/realtek/rtw89/reg.h | 4 +++
drivers/net/wireless/realtek/rtw89/usb.c | 41 ++++++++++++++++++++++++
2 files changed, 45 insertions(+)
--
2.53.0
^ permalink raw reply
* [PATCH 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Lucid Duck @ 2026-05-08 5:44 UTC (permalink / raw)
To: linux-wireless
Cc: Ping-Ke Shih, Bitterblue Smith, linux-kernel, Devin Wittmayer
In-Reply-To: <20260508054421.128938-1-lucid_duck@justthetip.ca>
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
The Realtek wifi 6/7 devices which support USB 3 are weird: when first
plugged in, they pretend to be USB 2. The driver needs to send some
commands to the device, which make it disappear and come back as a
USB 3 device.
Implement the required commands in rtw89.
When a USB 3 device is plugged into a USB 2 port, rtw89 will try to
switch it to USB 3 mode only once. The device will disappear and come
back still in USB 2 mode, of course.
Some people experience heavy interference in the 2.4 GHz band in
USB 3 mode, so add a module parameter switch_usb_mode with the
default value 1 to let people disable the switching.
Tested with RTL8832BU and RTL8832CU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
drivers/net/wireless/realtek/rtw89/reg.h | 4 +++
drivers/net/wireless/realtek/rtw89/usb.c | 41 ++++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/reg.h b/drivers/net/wireless/realtek/rtw89/reg.h
index 42ffe83931a3..7d4c085d9fb2 100644
--- a/drivers/net/wireless/realtek/rtw89/reg.h
+++ b/drivers/net/wireless/realtek/rtw89/reg.h
@@ -164,6 +164,10 @@
#define R_AX_DBG_PORT_SEL 0x00C0
#define B_AX_DEBUG_ST_MASK GENMASK(31, 0)
+#define R_AX_PAD_CTRL2 0x00C4
+#define U2SWITCHU3 0xB
+#define USB_SWITCH_DELAY 0xF
+
#define R_AX_PMC_DBG_CTRL2 0x00CC
#define B_AX_SYSON_DIS_PMCR_AX_WRMSK BIT(2)
diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index 767a95f759b1..4fb25791d118 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -9,6 +9,11 @@
#include "txrx.h"
#include "usb.h"
+static bool rtw89_switch_usb_mode = true;
+module_param_named(switch_usb_mode, rtw89_switch_usb_mode, bool, 0644);
+MODULE_PARM_DESC(switch_usb_mode,
+ "Set to N to disable switching to USB 3 mode to avoid potential interference in the 2.4 GHz band (default: Y)");
+
static void rtw89_usb_read_port_complete(struct urb *urb);
static void rtw89_usb_vendorreq(struct rtw89_dev *rtwdev, u32 addr,
@@ -1027,6 +1032,35 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
usb_set_intfdata(intf, NULL);
}
+static int rtw89_usb_switch_mode(struct rtw89_dev *rtwdev)
+{
+ struct rtw89_usb *rtwusb = rtw89_usb_priv(rtwdev);
+
+ if (!rtw89_switch_usb_mode)
+ return 0;
+
+ /* No known USB 3 devices with this chip. */
+ if (rtwdev->chip->chip_id == RTL8851B)
+ return 0;
+
+ if (rtwusb->udev->speed == USB_SPEED_SUPER)
+ return 0;
+
+ rtw89_debug(rtwdev, RTW89_DBG_HCI, "%s: pad_ctrl2: %#x %#x\n",
+ __func__,
+ rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 1),
+ rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 2));
+
+ /* Already tried to switch but it's a USB 2 port. */
+ if (rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 1) == USB_SWITCH_DELAY)
+ return 0;
+
+ rtw89_write8(rtwdev, R_AX_PAD_CTRL2 + 1, USB_SWITCH_DELAY);
+ rtw89_write8(rtwdev, R_AX_PAD_CTRL2 + 2, U2SWITCHU3);
+
+ return 1;
+}
+
int rtw89_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1059,6 +1093,13 @@ int rtw89_usb_probe(struct usb_interface *intf,
goto err_free_hw;
}
+ ret = rtw89_usb_switch_mode(rtwdev);
+ if (ret) {
+ /* Not a fail, but we do need to skip rtw89_core_register. */
+ ret = 0;
+ goto err_intf_deinit;
+ }
+
if (rtwusb->udev->speed == USB_SPEED_SUPER)
rtwdev->hci.dle_type = RTW89_HCI_DLE_TYPE_USB3;
else
--
2.53.0
^ permalink raw reply related
* Re: [PATCH ath-next 1/2] wifi: ath12k: Add support for handling incumbent signal interference in 6 GHz
From: Rameshkumar Sundaram @ 2026-05-08 6:13 UTC (permalink / raw)
To: Amith A, ath12k; +Cc: linux-wireless, Aishwarya R, Hari Chandrakanthan
In-Reply-To: <20260505143853.295368-2-amith.a@oss.qualcomm.com>
On 5/5/2026 8:08 PM, Amith A wrote:
> From: Aishwarya R <aishwarya.r@oss.qualcomm.com>
>
> When incumbent signal interference is detected by an AP/mesh interface
> operating in the 6 GHz band, as mandated by the FCC, it is expected to
> vacate the affected channels. The firmware indicates the interference to
> the host using the WMI_DCS_INTERFERENCE_EVENT.
>
> To handle the new WMI event, first parse it to retrieve the interference
> information. Next, validate the interference-detected channel and
> the interference bitmap. The interference bitmap received from the
> firmware uses a mapping where bit 0 corresponds to the primary
> 20 MHz segment, regardless of its position within the operating
> bandwidth. Bit 1 represents the next adjacent 20 MHz segment, bit 2
> the lower 20 MHz segment of the adjacent 40 MHz segment, and so
> on, progressing sequentially across the bandwidth. However, for userspace
> consumption via mac80211, this bitmap must be transformed into a
> standardized format such that each bit position directly maps to the
> corresponding sub-channel index within the operating bandwidth.
> Finally, indicate the transformed interference bitmap to mac80211, which
> then notifies userspace of the interference. Once the incumbent signal
> interference is detected, firmware suspends TX internally on the affected
> operating channel while userspace decides the mitigation action. Userspace
> is expected to trigger a channel switch or bandwidth reduction to mitigate
> the interference. Also, add a flag handling_in_progress to indicate that
> handling of interference is in progress. Set it to true after
> indicating to mac80211 about the interference. Reset the flag to false
> after the operating channel is switched by userspace. This prevents
> processing any further interference events when there is already a
> previous event being handled. Hence, further events are processed only
> after a channel switch request is received from userspace for the
> previous event.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
> Co-developed-by: Hari Chandrakanthan <quic_haric@quicinc.com>
> Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
> Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/core.h | 8 +
> drivers/net/wireless/ath/ath12k/mac.c | 46 +++
> drivers/net/wireless/ath/ath12k/wmi.c | 382 +++++++++++++++++++++++++
> drivers/net/wireless/ath/ath12k/wmi.h | 58 +++-
> 4 files changed, 493 insertions(+), 1 deletion(-)
>
{ ... }
> +static int
> +ath12k_wmi_incumbent_signal_interference_subtlv_parser(struct ath12k_base *ab,
> + u16 tag, u16 len,
> + const void *ptr,
> + void *data)
> +{
> + const struct ath12k_wmi_incumbent_signal_interference_params *info;
> + struct ath12k_wmi_incumbent_signal_interference_arg *arg = data;
> +
> + switch (tag) {
> + case WMI_TAG_DCS_INCUMBENT_SIGNAL_INTERFERENCE_TYPE:
> + info = ptr;
> +
should we validate len before accessing info ? or may be add an entry
for WMI_TAG_DCS_INCUMBENT_SIGNAL_INTERFERENCE_TYPE in
ath12k_wmi_tlv_policies so that ath12k_wmi_tlv_iter() can take care of
the validation.
> + arg->chan_width = le32_to_cpu(info->chan_width);
> + arg->chan_freq = le32_to_cpu(info->chan_freq);
> + arg->center_freq0 = le32_to_cpu(info->center_freq0);
> + arg->center_freq1 = le32_to_cpu(info->center_freq1);
> + arg->chan_bw_interference_bitmap =
> + le32_to_cpu(info->chan_bw_interference_bitmap);
> +
> + ath12k_dbg(ab, ATH12K_DBG_WMI,
> + "incumbent signal interference chan width %u freq %u center_freq0 %u center_freq1 %u bitmap 0x%x\n",
> + arg->chan_width, arg->chan_freq,
> + arg->center_freq0, arg->center_freq1,
> + arg->chan_bw_interference_bitmap);
> + break;
> + default:
> + ath12k_warn(ab, "Received invalid tag 0x%x for WMI DCS interference in subtlvs\n",
> + tag);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
--
Ramesh
^ permalink raw reply
* RE: [PATCH v2] wifi: rtw88: usb: fix memory leaks on USB write failures
From: Ping-Ke Shih @ 2026-05-08 6:16 UTC (permalink / raw)
To: Luka Gejak, Kalle Valo
Cc: Sascha Hauer, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <1C7E1191-635B-4806-946C-62DD1C82F79A@linux.dev>
Luka Gejak <luka.gejak@linux.dev> wrote:
> On May 8, 2026 5:47:55 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> >> From: Luka Gejak <luka.gejak@linux.dev>
> >>
> >> When rtw_usb_write_port() fails to submit a USB Request Block (URB)
> >> (e.g., due to device disconnect or ENOMEM), the completion callback is
> >> never executed.
> >>
> >> Currently, the driver ignores the return value of rtw_usb_write_port()
> >> in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
> >> functions rely on the completion callback to free the socket buffers
> >> (skbs) and the transaction control block (txcb), a submission failure
> >> results in:
> >> 1. A memory leak of the allocated skb in rtw_usb_write_data().
> >> 2. A memory leak of the txcb structure and all aggregated skbs in
> >> rtw_usb_tx_agg_skb().
> >>
> >> Fix this by checking the return value of rtw_usb_write_port(). If it
> >> fails, explicitly free the skb in rtw_usb_write_data(), and properly
> >> purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
> >>
> >> The issue was discovered in practice during device disconnect/reconnect
> >> scenarios and memory pressure conditions. Tested by verifying normal TX
> >> operation continues after the fix without regressions.
> >
> >Did the memory pressure condition happen? and falls into the cases you are
> >adding? This is main thing I want to know.
> >
> >>
> >> Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support")
> >
> >I don't find this commit touching the code related to this patch.
> >
> >> Cc: stable@vger.kernel.org
> >> Tested-by: Luka Gejak <luka.gejak@linux.dev>
> >> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> >> ---
> >> Changes in v2:
> >> - Use ret = rtw_usb_write_port(...); style, and check by next line (in
> >> rtw_usb_tx_agg_skb)
> >> - Remove unnecessary comment
> >> - Use ieee80211_purge_tx_queue() instead of skb_queue_purge()
> >
> >If it falls into the case, you will see some warnings without this change.
> >
> >Again, I'd like to know if OOM can happen in your test? If not, the test
> >you are doing will prove nothing, since your changes are executed only if OOM.
> >
> >> - Add testing details to commit message
> >>
> >
> While triggering a genuine OOM condition (-ENOMEM) during
> usb_submit_urb is admittedly difficult to force and rare in standard
> environments, my testing primarily relied on device disconnects.
> When a USB adapter is abruptly unplugged, rtw_usb_write_port()
> naturally fails to submit the URB
> (returning -ENODEV, -ESHUTDOWN, etc.).
I got the point that you did unplug the device.
> When this happens, the USB
> subsystem never executes the completion callback
> (rtw_usb_write_port_tx_complete or rtw_usb_write_port_complete).
> Because the original code ignored the return value of
> rtw_usb_write_port(), it leaked the skb and txcb structures every time
> a write was attempted immediately following a disconnect. Checking the
> return value catches this exact submission failure and frees the
> structures on the spot.
> And should I use commit that introduced USB support for Fixes tag?
I think it should be.
Ping-Ke
^ permalink raw reply
* RE: [PATCH 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Zenm Chen @ 2026-05-08 6:59 UTC (permalink / raw)
To: lucid_duck; +Cc: linux-kernel, linux-wireless, pkshih, rtl8821cerfe2
In-Reply-To: <20260508054421.128938-2-lucid_duck@justthetip.ca>
I don't remember Bitterblue allows you to upstream his work.
^ permalink raw reply
* [PATCH wireless 1/2] wifi: mac80211: fix MLE defragmentation
From: Johannes Berg @ 2026-05-08 7:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Miriam Rachel Korenblit, Ilan Peer
From: Johannes Berg <johannes.berg@intel.com>
If either reconf or EPCS multi-link element (MLE) is contained in
a non-transmitted profile, the defragmentation routine is called
with a pointer to the defragmented copy, but the original elements.
This is incorrect for two reasons:
- if the original defragmentation was needed, it will not find the
correct data
- if the original frame is at a higher address, the parsing will
potentially overrun the heap data (though given the layout of
the buffers, only into the new defragmentation buffer, and then
it has to stop and fail once that's filled with copied data.
Fix it by tracking the container along with the pointer and in
doing so also unify the two almost identical defragmentation
routines.
Fixes: 4d70e9c5488d ("wifi: mac80211: defragment reconfiguration MLE when parsing")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/parse.c | 71 +++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 40 deletions(-)
diff --git a/net/mac80211/parse.c b/net/mac80211/parse.c
index 2b3632c6008a..666cdd5fd0ea 100644
--- a/net/mac80211/parse.c
+++ b/net/mac80211/parse.c
@@ -34,6 +34,13 @@
#include "led.h"
#include "wep.h"
+struct ieee80211_elem_defrag {
+ const struct element *elem;
+ /* container start/len */
+ const u8 *start;
+ size_t len;
+};
+
struct ieee80211_elems_parse {
/* must be first for kfree to work */
struct ieee802_11_elems elems;
@@ -41,11 +48,7 @@ struct ieee80211_elems_parse {
/* The basic Multi-Link element in the original elements */
const struct element *ml_basic_elem;
- /* The reconfiguration Multi-Link element in the original elements */
- const struct element *ml_reconf_elem;
-
- /* The EPCS Multi-Link element in the original elements */
- const struct element *ml_epcs_elem;
+ struct ieee80211_elem_defrag ml_reconf, ml_epcs;
bool multi_link_inner;
bool skip_vendor;
@@ -162,10 +165,14 @@ ieee80211_parse_extension_element(u32 *crc,
}
break;
case IEEE80211_ML_CONTROL_TYPE_RECONF:
- elems_parse->ml_reconf_elem = elem;
+ elems_parse->ml_reconf.elem = elem;
+ elems_parse->ml_reconf.start = params->start;
+ elems_parse->ml_reconf.len = params->len;
break;
case IEEE80211_ML_CONTROL_TYPE_PRIO_ACCESS:
- elems_parse->ml_epcs_elem = elem;
+ elems_parse->ml_epcs.elem = elem;
+ elems_parse->ml_epcs.start = params->start;
+ elems_parse->ml_epcs.len = params->len;
break;
default:
break;
@@ -990,46 +997,27 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse,
sub->start, sub->len);
}
-static void
-ieee80211_mle_defrag_reconf(struct ieee80211_elems_parse *elems_parse)
+static const void *
+ieee80211_mle_defrag(struct ieee80211_elems_parse *elems_parse,
+ struct ieee80211_elem_defrag *defrag,
+ size_t *out_len)
{
- struct ieee802_11_elems *elems = &elems_parse->elems;
+ const void *ret;
ssize_t ml_len;
- ml_len = cfg80211_defragment_element(elems_parse->ml_reconf_elem,
- elems->ie_start,
- elems->total_len,
+ ml_len = cfg80211_defragment_element(defrag->elem,
+ defrag->start, defrag->len,
elems_parse->scratch_pos,
elems_parse->scratch +
elems_parse->scratch_len -
elems_parse->scratch_pos,
WLAN_EID_FRAGMENT);
if (ml_len < 0)
- return;
- elems->ml_reconf = (void *)elems_parse->scratch_pos;
- elems->ml_reconf_len = ml_len;
- elems_parse->scratch_pos += ml_len;
-}
-
-static void
-ieee80211_mle_defrag_epcs(struct ieee80211_elems_parse *elems_parse)
-{
- struct ieee802_11_elems *elems = &elems_parse->elems;
- ssize_t ml_len;
-
- ml_len = cfg80211_defragment_element(elems_parse->ml_epcs_elem,
- elems->ie_start,
- elems->total_len,
- elems_parse->scratch_pos,
- elems_parse->scratch +
- elems_parse->scratch_len -
- elems_parse->scratch_pos,
- WLAN_EID_FRAGMENT);
- if (ml_len < 0)
- return;
- elems->ml_epcs = (void *)elems_parse->scratch_pos;
- elems->ml_epcs_len = ml_len;
+ return NULL;
+ ret = elems_parse->scratch_pos;
+ *out_len = ml_len;
elems_parse->scratch_pos += ml_len;
+ return ret;
}
struct ieee802_11_elems *
@@ -1109,9 +1097,12 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)
_ieee802_11_parse_elems_full(&sub, elems_parse, NULL);
}
- ieee80211_mle_defrag_reconf(elems_parse);
-
- ieee80211_mle_defrag_epcs(elems_parse);
+ elems->ml_reconf = ieee80211_mle_defrag(elems_parse,
+ &elems_parse->ml_reconf,
+ &elems->ml_reconf_len);
+ elems->ml_epcs = ieee80211_mle_defrag(elems_parse,
+ &elems_parse->ml_epcs,
+ &elems->ml_epcs_len);
if (elems->tim && !elems->parse_error) {
const struct ieee80211_tim_ie *tim_ie = elems->tim;
--
2.53.0
^ permalink raw reply related
* [PATCH wireless 2/2] wifi: mac80211: fix multi-link element inheritance
From: Johannes Berg @ 2026-05-08 7:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Ilan Peer, Benjamin Berg
In-Reply-To: <20260508091031.8a6c34613178.I4de16ebbce2d27f2f8f98fc49949c7a376c2fe8d@changeid>
From: Johannes Berg <johannes.berg@intel.com>
When parsing a beacon, mac80211 erroneously inherits any
reconfiguration or EPCS multi-link elements from the outer
elements into the multi-BSSID profile that's requested, if
connected to a non-transmitted BSS, unless that profile
has a non-inheritance element.
This also happens if parsing a multi-BSSID profile that
doesn't have a non-inheritance element.
Fix this by having an empty non-inheritance element so
cfg80211_is_element_inherited() is invoked in these cases
and causes the parser to skip the elements that should
never be inherited.
Fixes: cf36cdef10e2 ("wifi: mac80211: Add support for parsing Reconfiguration Multi Link element")
Fixes: 24711d60f849 ("wifi: mac80211: Support parsing EPCS ML element")
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/parse.c | 36 +++++++++++++++++++++++++++++++++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/parse.c b/net/mac80211/parse.c
index 666cdd5fd0ea..77894d997113 100644
--- a/net/mac80211/parse.c
+++ b/net/mac80211/parse.c
@@ -34,6 +34,15 @@
#include "led.h"
#include "wep.h"
+static const u8 empty_non_inheritance[] = {
+ WLAN_EID_EXTENSION, 1, WLAN_EID_EXT_NON_INHERITANCE,
+ /*
+ * cfg80211_is_element_inherited() hardcodes elements that
+ * cannot be inherited, so we just need an empty one to be
+ * calling it at all.
+ */
+};
+
struct ieee80211_elem_defrag {
const struct element *elem;
/* container start/len */
@@ -923,7 +932,7 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse,
{
struct ieee802_11_elems *elems = &elems_parse->elems;
struct ieee80211_mle_per_sta_profile *prof;
- const struct element *tmp;
+ const struct element *tmp, *ret;
ssize_t ml_len;
const u8 *end;
@@ -993,8 +1002,17 @@ ieee80211_prep_mle_link_parse(struct ieee80211_elems_parse *elems_parse,
sub->from_ap = params->from_ap;
sub->link_id = -1;
- return cfg80211_find_ext_elem(WLAN_EID_EXT_NON_INHERITANCE,
- sub->start, sub->len);
+ ret = cfg80211_find_ext_elem(WLAN_EID_EXT_NON_INHERITANCE,
+ sub->start, sub->len);
+ if (ret)
+ return ret;
+
+ /*
+ * Since we know we want and found a profile, apply an empty
+ * non-inheritance if the profile didn't have one, so that any
+ * element that shouldn't be inherited by spec isn't.
+ */
+ return (const void *)empty_non_inheritance;
}
static const void *
@@ -1030,6 +1048,7 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)
size_t scratch_len = 3 * params->len;
bool multi_link_inner = false;
+ BUILD_BUG_ON(sizeof(empty_non_inheritance) != empty_non_inheritance[1] + 2);
BUILD_BUG_ON(offsetof(typeof(*elems_parse), elems) != 0);
/* cannot parse for both a specific link and non-transmitted BSS */
@@ -1077,6 +1096,17 @@ ieee802_11_parse_elems_full(struct ieee80211_elems_parse_params *params)
non_inherit = cfg80211_find_ext_elem(WLAN_EID_EXT_NON_INHERITANCE,
sub.start, nontx_len);
+ /*
+ * If it's a non-transmitted BSS, we shouldn't pick
+ * any elements in the outer parsing that shouldn't
+ * be inherited. If the profile has a non-inheritance
+ * element this automatically happens, but if not then
+ * provide an empty one so that the hard-coded elements
+ * in cfg80211_is_element_inherited() are ignored, but
+ * it must be called.
+ */
+ if (params->bss->transmitted_bss && !non_inherit)
+ non_inherit = (const void *)empty_non_inheritance;
} else {
/* must always parse to get elems_parse->ml_basic_elem */
non_inherit = ieee80211_prep_mle_link_parse(elems_parse, params,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] wifi: wlcore: Add support for IGTK key
From: Andreas Kemnade @ 2026-05-08 8:24 UTC (permalink / raw)
To: Peter Åstrand; +Cc: linux-wireless
In-Reply-To: <0d3df7ab-6c41-c3cc-83cc-5ba55fe4e4bd@lysator.liu.se>
Hi,
On Fri, 16 Jan 2026 18:58:58 +0100 (CET)
Peter Åstrand <astrand@lysator.liu.se> wrote:
> This change re-applies commit 2b7aadd3b9e1 ("wlcore: Adding suppoprt for IGTK key in
> wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern
> firmware. This patch is required to support WPA3 connections.
>
I have seen this after this patch:
[ 484.113311] wlcore: WARNING could not set keys
[ 484.117828] wlcore: ERROR Could not add or replace key
[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
[ 484.145721] wlcore: down
[ 484.148986] ieee80211 phy0: Hardware restart was requested
[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
[ 484.633758] wlcore: Association completed.
[ 484.690490] wlcore: ERROR command execute failure 14
[ 484.690490] ------------[ cut here ]------------
[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly.
As soon as I set pmf to 1 in wpa_supplciant, once per second. Reverting this patch helps. Seen this
on the Epson Moverio BT-200.
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Rameshkumar Sundaram @ 2026-05-08 10:17 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: ath11k, jjohnson, linux-kernel, linux-wireless, stable
In-Reply-To: <20260507070808.367442-1-jtornosm@redhat.com>
On 5/7/2026 12:38 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
>
> The hardwre that I am using is QCNFA765, but I think it is something
> related to ath11k driver and not related to some specific hardware.
>
> I am running with the latest upstream kernel and I can reproduce it, so
> I think it is not related with the problems that you comment.
>
> Let me repeat this to try to clarify:
>
> The easiest way to reproduce it is to run in a VM the default upstream
> kernel (with this card using PCI passthrough), and since this is always
> failing, just unbind the device (ath11k_pci).
What is the exact failure? Do you see any driver error logs when it occurs?
>
> The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
> ("wifi: ath12k: fix warning when unbinding"), and I have seen the same
> problem is also happening for ath11k driver.
>
Got it. I was just thinking along with the proposed fix — whether we
might also need to handle the sequencing on QMI failure.
In other words, do you think the issue(double free) would still be
reproducible if we include a change like below ?
index 1397756d6251..5bbb53a6b404 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -3295,7 +3295,11 @@ static void ath11k_qmi_driver_event_work(struct
work_struct *work)
clear_bit(ATH11K_FLAG_CRASH_FLUSH,
&ab->dev_flags);
clear_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags);
- ath11k_core_qmi_firmware_ready(ab);
+ ret = ath11k_core_qmi_firmware_ready(ab);
+ if (ret) {
+ set_bit(ATH11K_FLAG_QMI_FAIL,
&ab->dev_flags);
+ break;
+ }
set_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags);
break;
--
Ramesh
^ permalink raw reply related
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Jose Ignacio Tornos Martinez @ 2026-05-08 10:31 UTC (permalink / raw)
To: rameshkumar.sundaram
Cc: ath11k, jjohnson, jtornosm, linux-kernel, linux-wireless, stable
In-Reply-To: <336655c6-4dac-46e9-a783-549f0a9cccea@oss.qualcomm.com>
Hello Rameshkumar,
> What is the exact failure? Do you see any driver error logs when it occurs?
No error log, just the warning.
> Got it. I was just thinking along with the proposed fix — whether we
> might also need to handle the sequencing on QMI failure.
> In other words, do you think the issue(double free) would still be
> reproducible if we include a change like below ?
Yes, I think so and in addition the code is more robust.
There is no need to handle other stuff, the device can be bound again with
no problem.
Thanks
Best regards
José Ignacio
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Fix phandle-array constraints, again
From: Rob Herring @ 2026-05-08 13:20 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet, Paolo Abeni, Wolfram Sang,
Andrew Lunn, linux-kernel, linux-mmc, dri-devel, devicetree,
Johannes Berg, Bjorn Andersson, Krzysztof Wilczyński,
linux-arm-kernel, Jeff Johnson, linux-pci, Lorenzo Pieralisi,
linux-usb, Conor Dooley, ath11k, linux-spi, linux-remoteproc,
Ulf Hansson, Greg Kroah-Hartman, Andi Shyti,
Manivannan Sadhasivam, David S. Miller, Mathieu Poirier,
Maxime Ripard, Sylwester Nawrocki, linux-wireless, Mark Brown,
linux-sound, linux-i2c, Bjorn Helgaas, netdev, ath10k,
Krzysztof Kozlowski
In-Reply-To: <177818942584.2803269.2192622854542354589.robh@kernel.org>
On Thu, May 07, 2026 at 04:30:25PM -0500, Rob Herring (Arm) wrote:
>
> On Thu, 07 May 2026 15:16:00 -0500, Rob Herring (Arm) wrote:
> > The unfortunately named 'phandle-array' property type is really a matrix
> > with phandle and fixed arg cells entries. A matrix property should have 2
> > levels of items constraints.
> >
> > Acked-by: Mark Brown <broonie@kernel.org>
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> > ---
> > v2:
> > - Add proper descriptions for 'qcom,smem-states'. Thanks Krzysztof!
> > - Fix i2c-parent warning
> > - Fix extra blank lines
> > ---
> > .../rockchip/rockchip,rk3399-cdn-dp.yaml | 2 ++
> > .../bindings/i2c/i2c-demux-pinctrl.yaml | 1 +
> > .../mmc/hisilicon,hi3798cv200-dw-mshc.yaml | 7 ++++---
> > .../devicetree/bindings/net/qcom,bam-dmux.yaml | 12 ++++++++++++
> > .../devicetree/bindings/net/qcom,ipa.yaml | 12 ++++++++++++
> > .../bindings/net/wireless/qcom,ath10k.yaml | 8 +++++++-
> > .../bindings/net/wireless/qcom,ath11k.yaml | 8 +++++++-
> > .../net/wireless/qcom,ipq5332-wifi.yaml | 18 ++++++++++++++++++
> > .../bindings/pci/toshiba,tc9563.yaml | 5 +++--
> > .../remoteproc/qcom,msm8916-mss-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,msm8996-mss-pil.yaml | 7 +++++++
> > .../bindings/remoteproc/qcom,pas-common.yaml | 6 ++++++
> > .../remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,sc7180-mss-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,sc7280-adsp-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,sc7280-mss-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,sc7280-wpss-pil.yaml | 6 ++++++
> > .../remoteproc/qcom,sdm845-adsp-pil.yaml | 6 ++++++
> > .../bindings/remoteproc/qcom,wcnss-pil.yaml | 6 ++++++
> > .../devicetree/bindings/sound/samsung,tm2.yaml | 8 ++++++--
> > .../bindings/spi/st,stm32mp25-ospi.yaml | 5 +++--
> > .../bindings/usb/chipidea,usb2-common.yaml | 2 ++
> > .../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 ++++---
> > 23 files changed, 142 insertions(+), 14 deletions(-)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.example.dtb: i2c-mux3 (i2c-demux-pinctrl): i2c-parent:0: [2, 3, 4] is too long
> from schema $id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.example.dtb: i2c-mux3 (i2c-demux-pinctrl): i2c-parent: [[2, 3, 4]] is too short
> from schema $id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml
This needs a fix in dtschema I have not yet pushed out.
Rob
^ permalink raw reply
* [wireless-next:main] BUILD SUCCESS 6a4c4656b0d2d4056a1f0c35442db4e8a5cf8021
From: kernel test robot @ 2026-05-08 13:44 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Johannes Berg, linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
branch HEAD: 6a4c4656b0d2d4056a1f0c35442db4e8a5cf8021 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
elapsed time: 739m
configs tested: 279
configs skipped: 114
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc haps_hs_smp_defconfig gcc-15.2.0
arc nsimosci_hs_smp_defconfig gcc-15.2.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260508 gcc-12.5.0
arc randconfig-001-20260508 gcc-8.5.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260508 gcc-12.5.0
arc randconfig-002-20260508 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm defconfig gcc-15.2.0
arm neponset_defconfig gcc-15.2.0
arm randconfig-001 gcc-8.5.0
arm randconfig-001-20260508 gcc-12.5.0
arm randconfig-001-20260508 gcc-8.5.0
arm randconfig-002 gcc-11.5.0
arm randconfig-002 gcc-8.5.0
arm randconfig-002-20260508 gcc-10.5.0
arm randconfig-002-20260508 gcc-12.5.0
arm randconfig-002-20260508 gcc-8.5.0
arm randconfig-003 clang-20
arm randconfig-003 gcc-8.5.0
arm randconfig-003-20260508 gcc-12.5.0
arm randconfig-003-20260508 gcc-14.3.0
arm randconfig-003-20260508 gcc-8.5.0
arm randconfig-004 gcc-14.3.0
arm randconfig-004 gcc-8.5.0
arm randconfig-004-20260508 gcc-12.5.0
arm randconfig-004-20260508 gcc-13.4.0
arm randconfig-004-20260508 gcc-8.5.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260508 gcc-14.3.0
arm64 randconfig-001-20260508 gcc-8.5.0
arm64 randconfig-002-20260508 gcc-14.3.0
arm64 randconfig-002-20260508 gcc-8.5.0
arm64 randconfig-003-20260508 gcc-10.5.0
arm64 randconfig-003-20260508 gcc-14.3.0
arm64 randconfig-004-20260508 gcc-12.5.0
arm64 randconfig-004-20260508 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260508 gcc-14.3.0
csky randconfig-002-20260508 gcc-14.3.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260508 clang-23
hexagon randconfig-002-20260508 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260508 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260508 clang-20
i386 buildonly-randconfig-002-20260508 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260508 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260508 clang-20
i386 buildonly-randconfig-004-20260508 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260508 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260508 gcc-14
i386 defconfig clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001 clang-20
i386 randconfig-001-20260508 clang-20
i386 randconfig-001-20260508 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260508 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260508 clang-20
i386 randconfig-003-20260508 gcc-14
i386 randconfig-004 clang-20
i386 randconfig-004-20260508 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260508 gcc-12
i386 randconfig-005-20260508 gcc-14
i386 randconfig-006 gcc-14
i386 randconfig-006-20260508 gcc-14
i386 randconfig-007 gcc-14
i386 randconfig-007-20260508 clang-20
i386 randconfig-007-20260508 gcc-14
i386 randconfig-011-20260508 clang-20
i386 randconfig-011-20260508 gcc-13
i386 randconfig-012-20260508 gcc-13
i386 randconfig-013-20260508 clang-20
i386 randconfig-013-20260508 gcc-13
i386 randconfig-014-20260508 gcc-13
i386 randconfig-014-20260508 gcc-14
i386 randconfig-015-20260508 clang-20
i386 randconfig-015-20260508 gcc-13
i386 randconfig-016-20260508 clang-20
i386 randconfig-016-20260508 gcc-13
i386 randconfig-017-20260508 gcc-13
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260508 clang-23
loongarch randconfig-002-20260508 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
mips omega2p_defconfig clang-23
mips rt305x_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260508 clang-23
nios2 randconfig-002-20260508 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260508 gcc-9.5.0
parisc randconfig-002-20260508 gcc-9.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc holly_defconfig clang-23
powerpc randconfig-001-20260508 gcc-9.5.0
powerpc randconfig-002-20260508 gcc-9.5.0
powerpc tqm8555_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260508 gcc-9.5.0
powerpc64 randconfig-002-20260508 gcc-9.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260508 clang-23
riscv randconfig-002-20260508 clang-23
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260508 clang-23
s390 randconfig-002-20260508 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh polaris_defconfig gcc-15.2.0
sh randconfig-001-20260508 clang-23
sh randconfig-002-20260508 clang-23
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260508 gcc-12
sparc randconfig-002-20260508 gcc-12
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260508 gcc-12
sparc64 randconfig-002-20260508 gcc-12
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260508 gcc-12
um randconfig-002-20260508 gcc-12
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260508 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260508 clang-20
x86_64 buildonly-randconfig-002-20260508 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260508 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260508 clang-20
x86_64 buildonly-randconfig-004-20260508 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260508 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260508 clang-20
x86_64 buildonly-randconfig-006-20260508 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260508 clang-20
x86_64 randconfig-001-20260508 gcc-14
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260508 clang-20
x86_64 randconfig-003 clang-20
x86_64 randconfig-003-20260508 clang-20
x86_64 randconfig-004 clang-20
x86_64 randconfig-004-20260508 clang-20
x86_64 randconfig-004-20260508 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260508 clang-20
x86_64 randconfig-006 clang-20
x86_64 randconfig-006-20260508 clang-20
x86_64 randconfig-006-20260508 gcc-14
x86_64 randconfig-011-20260508 gcc-14
x86_64 randconfig-012-20260508 clang-20
x86_64 randconfig-012-20260508 gcc-14
x86_64 randconfig-013-20260508 gcc-14
x86_64 randconfig-014-20260508 gcc-14
x86_64 randconfig-015-20260508 gcc-14
x86_64 randconfig-016-20260508 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260508 clang-20
x86_64 randconfig-071-20260508 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260508 gcc-14
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260508 clang-20
x86_64 randconfig-073-20260508 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260508 clang-20
x86_64 randconfig-074-20260508 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260508 clang-20
x86_64 randconfig-075-20260508 gcc-14
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260508 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260508 gcc-12
xtensa randconfig-002-20260508 gcc-12
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] wifi: wlcore: Add support for IGTK key
From: Peter Åstrand @ 2026-05-08 13:55 UTC (permalink / raw)
To: Andreas Kemnade; +Cc: linux-wireless
In-Reply-To: <20260508102403.4e2fb1bc@kemnade.info>
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]
On Fri, 8 May 2026, Andreas Kemnade wrote:
> Hi,
>
> On Fri, 16 Jan 2026 18:58:58 +0100 (CET)
> Peter Åstrand <astrand@lysator.liu.se> wrote:
>
> > This change re-applies commit 2b7aadd3b9e1 ("wlcore: Adding suppoprt for IGTK key in
> > wlcore driver") (sic), but only enables WLAN_CIPHER_SUITE_AES_CMAC with modern
> > firmware. This patch is required to support WPA3 connections.
> >
>
> I have seen this after this patch:
> [ 484.113311] wlcore: WARNING could not set keys
> [ 484.117828] wlcore: ERROR Could not add or replace key
> [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
> [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
> [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
> [ 484.145721] wlcore: down
> [ 484.148986] ieee80211 phy0: Hardware restart was requested
> [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
> [ 484.633758] wlcore: Association completed.
> [ 484.690490] wlcore: ERROR command execute failure 14
> [ 484.690490] ------------[ cut here ]------------
> [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
>
> This repeats endlessly.
> As soon as I set pmf to 1 in wpa_supplciant, once per second. Reverting this patch helps. Seen this
> on the Epson Moverio BT-200.
Thanks for this feedback. From the firmware version, I assume that this is
not wl18xx but probably wl12xx? Unfortunately I have no experience with
that module. So, while my patch is an improvement over the original patch
because it checks firmware version, it did not consider non-wl18xx
modules.
I guess we need to throw in something like:
strcmp(pdev_data->family->name, "wl18xx")
...in the if statement.
Br,
Peter
^ 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