summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-11-24wifi: mt76: Introduce the NPU generic layerLorenzo Bianconi
Add the NPU generic layer in mt76 module. NPU will be used to enable traffic forward offloading between the MT76 NIC and the Airoha ethernet one available on the Airoha EN7581 SoC using Netfilter Flowtable APIs. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-4-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: Add the capability to set TX token start IDLorenzo Bianconi
This is a preliminary patch to enable traffic forward offloading via the Airoha NPU module available on the Airoha EN7581 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-3-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: Add mt76_dev pointer in mt76_queue struct.Lorenzo Bianconi
This is a preliminary patch to enable traffic forward offloading via the Airoha NPU module available on the Airoha EN7581 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-2-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: Move Q_READ/Q_WRITE definitions in dma.hLorenzo Bianconi
This is a preliminary patch to enable traffic forward offloading between the MT76 NIC and the Airoha ethernet one via the Airoha NPU module available on the Airoha EN7581 SoC. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251017-mt76-npu-devel-v2-1-ddaa90901723@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: mt7996: Remove useless check in mt7996_msdu_page_get_from_cache()Lorenzo Bianconi
Get rid of useless null-pointer check in mt7996_msdu_page_get_from_cache since we have already verfied the list is not empty. Fixes: b1e58e137b616 ("wifi: mt76: mt7996: Introduce RRO MSDU callbacks") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202510100155.MS0IXhzm-lkp@intel.com/ Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251014-mt7996_msdu_page_get_from_cache-remove-null-ptr-check-v1-1-fbeb7881e192@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: relicense to BSD-3-Clause-ClearFelix Fietkau
MediaTek has asked to switch from the ISC license to BSD-3-Clause-Clear, in order to improve clarity and the legal integrity of the code. The BSD-3-Clause license includes the "no endorsement" clause, which is important for protecting the reputation of the original authors and contributors by preventing unauthorized use of their names for endorsement purposes. This clause is absent in the BSD-2-Clause license, which is more permissive but lacks this specific protection. This change also cleans up the license of some Kconfig/Makefile files, which were accidentally marked as GPL. The GPL 2.0 remains in use on mt76x0, as well as two source files in mt7615 for which the license situation still needs to be clarified. Link: https://patch.msgid.link/20251008104250.46292-2-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: fix license/copyright of util.hFelix Fietkau
The extra copyright line for Ivo van Doorn and GPL license was only there because of code that I had already removed before the initial upstream submission of mt76. Remove it and make this header file use ISC license like the rest of the source files. Link: https://patch.msgid.link/20251008104250.46292-1-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: use GFP_DMA32 for page_pool buffer allocationPeter Chiu
Set GFP_DMA32 flag for page_pool buffers allocation since the hw relies on 32-bit DMA addresses for WED offloading. Tested-by: Daniel Pawlik <pawlik.dan@gmail.com> Tested-by: Matteo Croce <teknoraver@meta.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251008-wed-fixes-v1-2-8f7678583385@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacksLorenzo Bianconi
MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Tested-by: Daniel Pawlik <pawlik.dan@gmail.com> Tested-by: Matteo Croce <teknoraver@meta.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251008-wed-fixes-v1-1-8f7678583385@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: mt7915: add bf backoff limit table supportShayne Chen
The commit 22b980badc0f ("mt76: add functions for parsing rate power limits from DT") introduced generic support for rates limits in the devicetree. But the mt7915 supports beamforming and has another table for configuring the backoff limits. These can be configured in the DT with the paths-* properties. The path-*-bf are the ones relevant for beamforming and the ones without -bf suffix for "traditional" path backoff. Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de> Link: https://patch.msgid.link/20251007-backoff-table-support-v3-3-fd6e2684988f@simonwunderlich.de Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: Fix DTS power-limits on little endian systemsSven Eckelmann (Plasma Cloud)
The power-limits for ru and mcs and stored in the devicetree as bytewise array (often with sizes which are not a multiple of 4). These arrays have a prefix which defines for how many modes a line is applied. This prefix is also only a byte - but the code still tried to fix the endianness of this byte with a be32 operation. As result, loading was mostly failing or was sending completely unexpected values to the firmware. Since the other rates are also stored in the devicetree as bytewise arrays, just drop the u32 access + be32_to_cpu conversion and directly access them as bytes arrays. Cc: stable@vger.kernel.org Fixes: 22b980badc0f ("mt76: add functions for parsing rate power limits from DT") Fixes: a9627d992b5e ("mt76: extend DT rate power limits to support 11ax devices") Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: connac: Replace memcpy + hard-coded size with strscpyThorsten Blum
Replace memcpy() and the hard-coded string length with strscpy() to safely copy the string and improve mt76_connac_mcu_chip_config(). No functional changes. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20250923213831.1896823-2-thorsten.blum@linux.dev Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: mt7996: Remove unnecessary link_id checks in mt7996_txLorenzo Bianconi
Remove unnecessary link_id checks in mt7996_tx routine since if the link identifier provided by mac80211 is unspecified the value will be overwritten at the beginning on the function. Fixes: f940c9b7aef6 ("wifi: mt76: mt7996: Set proper link destination address in mt7996_tx()") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250924-mt76_tx_unnecessary-check-v1-1-e595930a5662@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()Felix Fietkau
If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link. Fixes: c0df2f0caa8d ("wifi: mt76: mt7996: prepare mt7996_mcu_set_tx for MLO support") Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250929111723.52486-1-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-11-24wifi: brcmfmac: Add DMI nvram filename quirk for Acer A1 840 tabletHans de Goede
The Acer A1 840 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: brcmfmac43340-sdio.Insyde-BayTrail.txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the Acer A1 840 tablet. Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20251103100314.353826-1-hansg@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-24Merge tag 'rtw-next-2025-11-21-v2' of https://github.com/pkshih/rtwJohannes Berg
Ping-Ke Shih says: ================== rtw-next patches for v6.19 Main changes are about rtw89 USB support, which two USB devices are added with proper TX status, and other notable items are listed below. rtl8xxxu: - fix 40MHz bandwidth connection rtw89: - support USB devices RTL8852AU and RTL8852CU - report TX status from air for USB devices - resolve racing between processes of TX and TX report - resolve racing of skb queue of C2H events - support injected packets with bandwidth and data rate - more materials for coming RTL8922DE ================== Link: https://patch.msgid.link/45eed1763a354460acba15a8e69f9e3e@realtek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-23wifi: iwlwifi: trans: rename at_least variable to min_modeJason A. Donenfeld
The subsequent commit is going to add a macro that redefines `at_least` to mean something else. Given that the usage here in iwlwifi is the only use of that identifier in the whole kernel, just rename it to a more fitting name, `min_mode`. Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: "Jason A. Donenfeld" <Jason@zx2c4.com> Link: https://lore.kernel.org/r/20251123054819.2371989-1-Jason@zx2c4.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-21wifi: rtl8xxxu: Enable 40 MHz width by defaultBitterblue Smith
40 MHz support is hidden behind the ht40_2g module parameter with this comment: /* * Some APs will negotiate HT20_40 in a noisy environment leading * to miserable performance. Rather than defaulting to this, only * enable it if explicitly requested at module load time. */ This parameter was added in commit 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU and the RTL8192CU family. It's entirely possible the miserable performance was due to mistakes in the channel switching function, which were fixed in a previous patch. Delete the ht40_2g module parameter. If someone still needs to disable 40 MHz support, cfg80211 has the module parameter cfg80211_disable_40mhz_24ghz. That works too. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4f053103-adfd-4ead-acb3-ef69127a4bab@gmail.com
2025-11-21wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FUBitterblue Smith
The other chips report the RX channel width in the RX descriptor, but this one doesn't. Get the RX channel width from the PHY status. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1c6c1fd4-92f6-4327-a24e-f0747ab21819@gmail.com
2025-11-21wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BUBitterblue Smith
rtl8xxxu_gen2_config_channel() was missing the subchannel setting. This function is used by RTL8192EU and RTL8723BU. This change seems to make no difference in my testing on channel 13 with either chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a5de8d39-45c1-4667-ab4c-7109de6eb13d@gmail.com
2025-11-21wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz widthBitterblue Smith
Set the required fields in the TX descriptor to allow these chips to transmit with 40 MHz channel width when the access point supports it. Tested only with RTL8192CU, but these settings are identical for RTL8723AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/30d95228-69b2-48f9-8854-c98d2408c4d3@gmail.com
2025-11-21wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AUBitterblue Smith
Flip the response rate subchannel. It was backwards, causing low speeds when using 40 MHz channel width. "iw dev ... station dump" showed a low RX rate, 11M or less. Also fix the channel width field of RF6052_REG_MODE_AG. Tested only with RTL8192CU, but these settings are identical for RTL8723AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1f46571d-855b-43e1-8bfc-abacceb96043@gmail.com
2025-11-21wifi: rtw89: 8852a: correct field mask of reset DAC/ADC FIFOPing-Ke Shih
The field mask should be bits 16-31, but suddenly use wrong bits 24-31, rarely causing a little performance degraded if DAC/DAC FIFO stays on an unexpected state. Found this by Geert who works on bit field functions. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/linux-wireless/CAMuHMdVt+5yOA6tuasX4KQgZud5wtRwu0A15UkEfQJbcd_xvVw@mail.gmail.com/ Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251120031044.12493-2-pkshih@realtek.com
2025-11-21wifi: rtw88: add WQ_UNBOUND to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds the WQ_UNBOUND flag to explicitly request alloc_workqueue() to be unbound, because this specific workload has no benefit being per-cpu. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118102032.54375-3-marco.crivellari@suse.com
2025-11-21wifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds the WQ_UNBOUND flag to explicitly request alloc_workqueue() to be unbound, because this specific workload has no benefit being per-cpu. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118102032.54375-2-marco.crivellari@suse.com
2025-11-21wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()Seungjin Bae
The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails. Fixes: 6f7853f3cbe4 ("rtl8187: change rtl8187_dev.c to support RTL8187B (part 2)") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118013258.1789949-2-eeodqql09@gmail.com
2025-11-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.18-rc7). No conflicts, adjacent changes: tools/testing/selftests/net/af_unix/Makefile e1bb28bf13f4 ("selftest: af_unix: Add test for SO_PEEK_OFF.") 45a1cd8346ca ("selftests: af_unix: Add tests for ECONNRESET and EOF semantics") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20wifi: ipw2x00: replace use of system_wq with system_percpu_wqMarco Crivellari
This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen after a careful review and conversion of each individual case, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> systemd_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20251120094524.45264-1-marco.crivellari@suse.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-20wifi: cw1200: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Link: https://patch.msgid.link/20251113162032.394804-3-marco.crivellari@suse.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-20wifi: wfx: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://patch.msgid.link/20251113160825.383883-1-marco.crivellari@suse.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-20wifi: qtnfmac: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Link: https://patch.msgid.link/20251113160035.376524-1-marco.crivellari@suse.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-20wifi: rtw89: hw_scan: Don't let the operating channel be lastBitterblue Smith
Scanning can be offloaded to the firmware. To that end, the driver prepares a list of channels to scan, including periodic visits back to the operating channel, and sends the list to the firmware. When the channel list is too long to fit in a single H2C message, the driver splits the list, sends the first part, and tells the firmware to scan. When the scan is complete, the driver sends the next part of the list and tells the firmware to scan. When the last channel that fit in the H2C message is the operating channel something seems to go wrong in the firmware. It will acknowledge receiving the list of channels but apparently it will not do anything more. The AP can't be pinged anymore. The driver still receives beacons, though. One way to avoid this is to split the list of channels before the operating channel. Affected devices: * RTL8851BU with firmware 0.29.41.3 * RTL8832BU with firmware 0.29.29.8 * RTL8852BE with firmware 0.29.29.8 The commit 57a5fbe39a18 ("wifi: rtw89: refactor flow that hw scan handles channel list") is found by git blame, but it is actually to refine the scan flow, but not a culprit, so skip Fixes tag. Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/ Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c1e61744-8db4-4646-867f-241b47d30386@gmail.com
2025-11-18wifi: rtw89: Add default ID 0bda:b831 for RTL8831BUZenm Chen
Add 0bda:b831 for RTL8831BU-based adapters that use this default ID. Tested with TOTOLINK X900USM in station mode very briefly. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251116234403.8803-1-zenmchen@gmail.com
2025-11-18wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()Abdun Nihaal
In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free. Fixes: f653211197f3 ("Add rtl8180 wireless driver") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114094527.79842-1-nihaal@cse.iitm.ac.in
2025-11-18wifi: rtw89: use separated function to set RX filterPing-Ke Shih
Normally use rtw89_write32_mask() with a consecutive bit mask, but mask of RX filter B_AX_RX_FLTR_CFG_MASK is bits 31-22 and 15-0, which excludes bits of B_AX_RX_MPDU_MAX_LEN_MASK (bits 21-16). Though the original logic is well to set RX filter, change it to a separate function to avoid the tricky design. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251113053459.34995-1-pkshih@realtek.com
2025-11-18wifi: rtw89: correct user macid mask of RX info for RTL8922DChih-Kang Chang
The user MAC ID mask of RX info in MAC PPDU for RTL8922A and RTL8922D is different, correct it accordingly. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-15-pkshih@realtek.com
2025-11-18wifi: rtw89: update format of addr cam H2C commandChih-Kang Chang
The addr cam H2C command is to tell firmware the addr related info. For RTL8922D and RTL8922A after firmware version 0.35.84.0, the addr cam must be updated with update mode to avoid clearing previously set fields. Update it accordingly. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-14-pkshih@realtek.com
2025-11-18wifi: rtw89: add addr cam H2C command v1Ping-Ke Shih
The coming RTL8922D uses different format of address CAM command, so add the new format accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-13-pkshih@realtek.com
2025-11-18wifi: rtw89: fill addr cam H2C command by structPing-Ke Shih
The addr cam is used to tell firmware the MAC address and BSSID associated to connected stations. Use struct instead of macros with pointer arithmetic to fill the data. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-12-pkshih@realtek.com
2025-11-18wifi: rtw89: align RA H2C format v1 for RTL8922APing-Ke Shih
For RTL8922A, the bits [16:31] of word 3 of v1 format isn't as WiFi 6 chips. Instead, it only needs to fill additional band type and partial bandwidth ER. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-11-pkshih@realtek.com
2025-11-18wifi: rtw89: fw: print band and port where beacon update onPing-Ke Shih
The C2H event of BCN_UPD_DONE is to notify driver that firmware changes beacon content on certain band/port asked by driver. Print the notification for debug purpose for now. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-10-pkshih@realtek.com
2025-11-18wifi: rtw89: phy: ignore DCFO if not defined in chip_infoPing-Ke Shih
For WiFi 7 chips, DCFO (digital carrier frequency offset) feature isn't supported, so the corresponding registers aren't defined in chip_info. Check and ignore this feature accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-9-pkshih@realtek.com
2025-11-18wifi: rtw89: phy: consider type 15 in BB gain tablePing-Ke Shih
BB gain table is a table to configure gain for certain channels. Newly added type 15 is considered to write registers accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-8-pkshih@realtek.com
2025-11-18wifi: rtw89: mac: update wcpu_on to download firmware for RTL8922DPing-Ke Shih
The RTL8922D does more settings before downloading firmware, so add them accordingly. Also, update the missed settings for RTL8922A. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-7-pkshih@realtek.com
2025-11-18wifi: rtw89: mac: remove undefined bit B_BE_PPDU_MAC_INFOPing-Ke Shih
The bit is defined during test chip development, but formal chips don't have this. Remove it. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-6-pkshih@realtek.com
2025-11-18wifi: rtw89: phy: calling BB pre-init by chips with/without BB MCUPing-Ke Shih
The existing flow is doing BB pre-init before downloading BB MCU firmware, because existing chip RTL8922A has BB MCU. However, the coming chips don't have this, and BB pre-init configuring registers can affect downloading WiFi-CPU firmware. Therefore, calling BB pre-init afterward for new coming chips without BB MCU. For existing WiFi 6 chips, no BB pre-init. For RTL8922A, don't change the logic. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-5-pkshih@realtek.com
2025-11-18wifi: rtw89: mac: separate pre-init code before downloading firmwarePing-Ke Shih
Driver needs to initialize registers before downloading firmware, so move pre-init part (power on) from original rtw89_mac_init(). The consequence patches will add more pre-init codes before downloading firmware. Since rtw89_phy_init_bb_afe() is used by coming RTL8922D, don't change logic at all for existing chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-4-pkshih@realtek.com
2025-11-18wifi: rtw89: fw: part size to download firmware by header infoPing-Ke Shih
The part size is the unit to download firmware piece by piece. Old chips use 2020 bytes as a piece, but in new chips the part size is defined in firmware header. Change to use the value dynamically. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-3-pkshih@realtek.com
2025-11-18wifi: rtw89: flush TX queue before deleting keyChih-Kang Chang
In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through nl80211_tx_control_port() and triggers wake_tx_queue() in the driver. Then, it sends nl80211_new_key() to configure a new key in mac80211. However, in wake_tx_queue(), a workqueue is used to process the TX packet, which might cause the driver to process the EAPOL packet later than nl80211_new_key(). This results in the EAPOL packet 4/4 being transmitted with the new key and IV, causing it to be dropped by the AP. Therefore, needs to flush TX queue before deleting the old key to ensure that the EAPOL 4/4 packet is transmitted using the old key. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251114060128.35363-2-pkshih@realtek.com
2025-11-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.18-rc6). No conflicts, adjacent changes in: drivers/net/phy/micrel.c 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface") 61b7ade9ba8c ("net: phy: micrel: Add support for non PTP SKUs for lan8814") and a trivial one in tools/testing/selftests/drivers/net/Makefile. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2026-01-16 22:24:46 +0000