summaryrefslogtreecommitdiff
path: root/drivers/net
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-21net: stmmac: qcom-ethqos: use read_poll_timeout_atomic()Russell King (Oracle)
Use read_poll_timeout_atomic() to poll the rgmii registers rather than open-coding the polling. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vM2n1-0000000FRTu-0js9@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-21net: stmmac: qcom-ethqos: add rgmii set/clear functionsRussell King (Oracle)
The driver has a lot of bit manipulation of the RGMII registers. Add a pair of helpers to set bits and clear bits, converting the various calls to rgmii_updatel() as appropriate. Most of the change was done via this sed script: /rgmii_updatel/ { N /,$/N /mask, / ! { s|rgmii_updatel\(([^,]*,\s+([^,]*),\s+)\2,\s+|rgmii_setmask(\1| s|rgmii_updatel\(([^,]*,\s+([^,]*),\s+)0,\s+|rgmii_clrmask(\1| s|^\s+$|| } } and then formatting tweaked where necessary. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/E1vM2mw-0000000FRTo-0End@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-21net: stmmac: qcom-ethqos: use u32 for rgmii read/write/updateRussell King (Oracle)
readl() returns a u32, and writel() takes a "u32" for the value. These are used in rgmii_readl()() and rgmii_writel(), but the value and return are "int". As these are 32-bit register values which are not signed, use "u32". These changes do not cause generated code changes. Update rgmii_updatel() to use u32 for mask and val. Changing "mask" to "u32" also does not cause generated code changes. However, changing "val" causes the generated assembly to be re-ordered for aarch64. Update the temporary variables used with the rgmii functions to use u32. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/E1vM2mq-0000000FRTi-3y5F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-21net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHYDaniel Golle
As the interface mode doesn't need to be updated on PHYs connected with USXGMII and integrated PHYs, gpy_update_interface() should just return 0 in these cases rather than -EINVAL which has wrongly been introduced by commit 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type"), as this breaks support for those PHYs. Fixes: 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/f744f721a1fcc5e2e936428c62ff2c7d94d2a293.1763648168.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-21net: wwan: t7xx: Make local function staticSlark Xiao
This function was used in t7xx_hif_cldma.c only. Make it static as it should be. Signed-off-by: Slark Xiao <slark_xiao@163.com> Reviewed-by: Loic Poulain <loic.poulain@qualcomm.com> Link: https://patch.msgid.link/20251120115208.345578-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski <kuba@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-20netdevsim: register a new devlink param with default value interfaceDaniel Zahka
Create a new devlink param, test2, that supports default param actions via the devlink_param::get_default() and devlink_param::reset_default() functions. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-6-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net/mlx5: implement swp_l4_csum_mode via devlink paramsDaniel Zahka
swp_l4_csum_mode controls how L4 transmit checksums are computed when using Software Parser (SWP) hints for header locations. Supported values: 1. default: device will choose between full_csum or l4_only. Driver will discover the device's choice during initialization. 2. full_csum: calculate L4 checksum with the pseudo-header. 3. l4_only: calculate L4 checksum without the pseudo-header. Only available when swp_l4_csum_mode_l4_only is set in mlx5_ifc_nv_sw_offload_cap_bits. Note that 'default' might be returned from the device and passed to userspace, and it might also be set during a devlink_param::reset_default() call, but attempts to set a value of default directly with param-set will be rejected. The l4_only setting is a dependency for PSP initialization in mlx5e_psp_init(). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-5-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20devlink: pass extack through to devlink_param::get()Daniel Zahka
Allow devlink_param::get() handlers to report error messages via extack. This function is called in a few different contexts, but not all of them will have an valid extack to use. When devlink_param::get() is called from param_get_doit or param_get_dumpit contexts, pass the extack through so that drivers can report errors when retrieving param values. devlink_param::get() is called from the context of devlink_param_notify(), pass NULL in for the extack. Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-2-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Increase MAX_USERDATA_ITEMSGustavo Luiz Duarte
Increase MAX_USERDATA_ITEMS from 16 to 256 entries now that the userdata buffer is allocated dynamically. The previous limit of 16 was necessary because the buffer was statically allocated for all targets. With dynamic allocation, we can support more entries without wasting memory on targets that don't use userdata. This allows users to attach more metadata to their netconsole messages, which is useful for complex debugging and logging scenarios. Also update the testcase accordingly. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-4-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Dynamic allocation of userdata bufferGustavo Luiz Duarte
The userdata buffer in struct netconsole_target is currently statically allocated with a size of MAX_USERDATA_ITEMS * MAX_EXTRADATA_ENTRY_LEN (16 * 256 = 4096 bytes). This wastes memory when userdata entries are not used or when only a few entries are configured, which is common in typical usage scenarios. It also forces us to keep MAX_USERDATA_ITEMS small to limit the memory wasted. Change the userdata buffer from a static array to a dynamically allocated pointer. The buffer is now allocated on-demand in update_userdata() whenever userdata entries are added, modified, or removed via configfs. The implementation calculates the exact size needed for all current userdata entries, allocates a new buffer of that size, formats the entries into it, and atomically swaps it with the old buffer. This approach provides several benefits: - Memory efficiency: Targets with no userdata use zero bytes instead of 4KB, and targets with userdata only allocate what they need; - Scalability: Makes it practical to increase MAX_USERDATA_ITEMS to a much larger value without imposing a fixed memory cost on every target; - No hot-path overhead: Allocation occurs during configuration (write to configfs), not during message transmission If memory allocation fails during userdata update, -ENOMEM is returned to userspace through the configfs attribute write operation. The sysdata buffer remains statically allocated since it has a smaller fixed size (MAX_SYSDATA_ITEMS * MAX_EXTRADATA_ENTRY_LEN = 4 * 256 = 1024 bytes) and its content length is less predictable. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-3-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Split userdata and sysdataGustavo Luiz Duarte
Separate userdata and sysdata into distinct buffers to enable independent management. Previously, both were stored in a single extradata_complete buffer with a fixed size that accommodated both types of data. This separation allows: - userdata to grow dynamically (in subsequent patch) - sysdata to remain in a small static buffer - removal of complex entry counting logic that tracked both types together The split also simplifies the code by eliminating the need to check total entry count across both userdata and sysdata when enabling features, which allows to drop holding su_mutex on sysdata_*_enabled_store(). No functional change in this patch, just structural preparation for dynamic userdata allocation. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-2-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Simplify send_fragmented_body()Gustavo Luiz Duarte
Refactor send_fragmented_body() to use separate offset tracking for msgbody, and extradata instead of complex conditional logic. The previous implementation used boolean flags and calculated offsets which made the code harder to follow. The new implementation maintains independent offset counters (msgbody_offset, extradata_offset) and processes each section sequentially, making the data flow more straightforward and the code easier to maintain. This is a preparatory refactoring with no functional changes, which will allow easily splitting extradata_complete into separate userdata and sysdata buffers in the next patch. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-1-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20eth: fbnic: access @pp through netmem_desc instead of pageByungchul Park
To eliminate the use of struct page in page pool, the page pool users should use netmem descriptor and APIs instead. Make fbnic access @pp through netmem_desc instead of page. Signed-off-by: Byungchul Park <byungchul@sk.com> Link: https://patch.msgid.link/20251120011118.73253-1-byungchul@sk.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20veth: reduce XDP no_direct return section to fix raceJesper Dangaard Brouer
As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing old or uninitialized descriptors") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct(). Fixes: 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/176356963888.337072.4805242001928705046.stgit@firesoul Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: fec: remove duplicate macros of the BD statusWei Fang
There are two sets of macros used to define the status bits of TX and RX BDs, one is the BD_SC_xx macros, the other one is the BD_ENET_xx macros. For the BD_SC_xx macros, only BD_SC_WRAP is used in the driver. But the BD_ENET_xx macros are more widely used in the driver, and they define more bits of the BD status. Therefore, remove the BD_SC_xx macros from now on. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251119025148.2817602-6-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: fec: remove rx_align from fec_enet_privateWei Fang
The rx_align was introduced by the commit 41ef84ce4c72 ("net: fec: change FEC alignment according to i.mx6 sx requirement"). Because the i.MX6 SX requires RX buffer must be 64 bytes alignment. Since the commit 95698ff6177b ("net: fec: using page pool to manage RX buffers"), the address of the RX buffer is always the page address plus FEC_ENET_XDP_HEADROOM which is 256 bytes, so the RX buffer is always 64-byte aligned. Therefore, rx_align has no effect since that commit, and we can safely remove it. In addition, to prevent future modifications to FEC_ENET_XDP_HEADROOM, a BUILD_BUG_ON() test has been added to the driver, which ensures that FEC_ENET_XDP_HEADROOM provides the required alignment. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251119025148.2817602-5-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: fec: remove struct fec_enet_priv_txrx_infoWei Fang
The struct fec_enet_priv_txrx_info has three members: offset, page and skb. The offset is only initialized in the driver and is not used, the skb is never initialized and used in the driver. The both will not be used in the future. Therefore, replace struct fec_enet_priv_txrx_info directly with struct page. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251119025148.2817602-4-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: fec: simplify the conditional preprocessor directivesWei Fang
From the Kconfig file, we can see CONFIG_FEC depends on the following platform-related options. ColdFire: M523x, M527x, M5272, M528x, M520x and M532x S32: ARCH_S32 (ARM64) i.MX: SOC_IMX28 and ARCH_MXC (ARM and ARM64) Based on the code of fec driver, only some macro definitions on the M5272 platform are different from those on other platforms. Therefore, we can simplify the following complex preprocessor directives to "if !defined(CONFIG_M5272)". "#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || \ defined(CONFIG_M528x) || defined(CONFIG_M520x) || \ defined(CONFIG_M532x) || defined(CONFIG_ARM) || \ defined(CONFIG_ARM64)" Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251119025148.2817602-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: fec: remove useless conditional preprocessor directivesWei Fang
The conditional preprocessor directive was added to fix build errors on the MCF5272 platform, see commit d13919301d9a ("net: fec: Fix build for MCF5272"). The compilation errors were originally caused by some register macros not being defined on that platform. The driver now uses quirks to dynamically handle platform differences, and for MCF5272, its quirks is 0, so it does not support RACC and GBIT Ethernet. So these preprocessor directives are no longer required and can be safely removed without causing build or functional issue. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251119025148.2817602-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20bonding: 3ad: Add support for 1600G speedYael Chemla
Add support for 1600Gbps speed to allow using 3ad mode with 1600G devices. Signed-off-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763585297-1243980-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net/mlx5e: Add 1600Gbps link modesYael Chemla
Introduce support for a 1600Gbps link mode, utilizing 8 lanes at 200Gbps per lane. Signed-off-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763585297-1243980-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net: ethtool: Add support for 1600Gbps speedYael Chemla
Add support for 1600Gbps link modes based on 200Gbps per lane [1]. This includes the adopted IEEE 802.3dj copper and optical PMDs that use 200G/lane signaling [2]. Add the following PMD types: - KR8 (backplane) - CR8 (copper cable) - DR8 (SMF 500m) - DR8-2 (SMF 2km) These modes are defined in the 802.3dj specifications. References: [1] https://www.ieee802.org/3/dj/public/23_03/opsasnick_3dj_01a_2303.pdf [2] https://www.ieee802.org/3/dj/projdoc/objectives_P802d3dj_240314.pdf Signed-off-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/1763585297-1243980-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netdevsim: add loopback supportJakub Kicinski
Support device loopback. Apparently this mode has been historically supported by the toeplitz test and I don't have any HW which lets me test the conversion.. Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20251120021024.2944527-12-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netdevsim: pass packets thru GRO on RxJakub Kicinski
To replace veth in software GRO testing with netdevsim we need GRO support in netdevsim. Luckily we already have NAPI support so this change is trivial (compared to veth). Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20251120021024.2944527-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 01:33:28 +0000