summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-02-28octeontx2-af: npc: cn20k: MKEX profile supportSuman Ghosh
In new silicon variant cn20k, a new parser profile is introduced. Instead of having two layer-data information per key field type, a new key extractor concept is introduced. As part of this change now a maximum of 24 extractor can be configured per packet parsing profile. For example, LA type(ether) can have 24 unique parsing key, LC type(ip), LD type(tcp/udp) also can have unique 24 parsing key associated. Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-5-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Add default profileSuman Ghosh
Default mkex profile for cn20k silicon. This commit changes attribute of objects to may_be_unused to avoid compiler warning Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-4-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: KPM profile changesSuman Ghosh
KPU (Kangaroo Processing Unit) profiles are primarily used to set the required packet pointers that will be used in later stages for key generation. In the new CN20K silicon variant, a new KPM profile is introduced alongside the existing KPU profiles. In CN20K, a total of 16 KPUs are grouped into 8 KPM profiles. As per the current hardware design, each KPM configuration contains a combination of 2 KPUs: KPM0 = KPU0 + KPU8 KPM1 = KPU1 + KPU9 ... KPM7 = KPU7 + KPU15 This configuration enables more efficient use of KPU resources. This patch adds support for the new KPM profile configuration. Signed-off-by: Suman Ghosh <sumang@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-3-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28octeontx2-af: npc: cn20k: Index managementRatheesh Kannoth
In CN20K silicon, the MCAM is divided vertically into two banks. Each bank has a depth of 8192. The MCAM is divided horizontally into 32 subbanks, with each subbank having a depth of 256. Each subbank can accommodate either x2 keys or x4 keys. x2 keys are 256 bits in size, and x4 keys are 512 bits in size. Bank1 Bank0 |-----------------------------| | | | subbank 31 { depth 256 } | | | |-----------------------------| | | | subbank 30 | | | ------------------------------ ............................... |-----------------------------| | | | subbank 0 | | | ------------------------------| This patch implements the following allocation schemes in NPC. The allocation API accepts reference (ref), limit, contig, priority, and count values. For example, specifying ref=100, limit=200, contig=1, priority=LOW, and count=20 will allocate 20 contiguous MCAM entries between entries 100 and 200. 1. Contiguous allocation with ref, limit, and priority. 2. Non-contiguous allocation with ref, limit, and priority. 3. Non-contiguous allocation without ref. 4. Contiguous allocation without ref. Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260224080009.4147301-2-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handlerGuenter Roeck
Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler") introduces a range check for if_id to avoid an out-of-bounds access. If an out-of-bounds if_id is detected, the interrupt status is not cleared. This may result in an interrupt storm. Clear the interrupt status after detecting an out-of-bounds if_id to avoid the problem. Found by an experimental AI code review agent at Google. Fixes: 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler") Cc: Junrui Luo <moonafterrain@outlook.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20260227055812.1777915-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28gve: Enable reading max ring size from the device in DQO-QPL modeMatt Olson
The gVNIC device indicates a device option (MODIFY_RING) to the driver, which presents a range of ring sizes from which the user is allowed to select. But in DQO-QPL queue format, the driver ignores the "max" of this range and instead allows the user to configure the ring size in the range [min, default]. This was done because increasing the ring size could result in the number of registered pages being higher than the max allowed by the device. In order to support large ring sizes, stop ignoring the "max" of the range presented in the MODIFY_RING option. Signed-off-by: Matt Olson <maolson@google.com> Signed-off-by: Max Yuan <maxyuan@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260225182342.1049816-3-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28gve: Update QPL page registration logicMatt Olson
For DQO, change QPL page registration logic to be more flexible to honor the "max_registered_pages" parameter from the gVNIC device. Previously the number of RX pages per QPL was hardcoded to twice the ring size, and the number of TX pages per QPL was dictated by the device in the DQO-QPL device option. Now [in DQO-QPL mode], the driver will ignore the "tx_pages_per_qpl" parameter indicated in the DQO-QPL device option and instead allocate up to (tx_queue_length / 2) pages per TX QPL and up to (rx_queue_length * 2) pages per RX QPL while keeping the total number of pages under the "max_registered_pages". Merge DQO and GQI QPL page calculation logic into a unified gve_update_num_qpl_pages function. Add rx_pages_per_qpl to the priv struct for consumption by both DQO and GQI. Signed-off-by: Matt Olson <maolson@google.com> Signed-off-by: Max Yuan <maxyuan@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20260225182342.1049816-2-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-28Merge branch '200GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-02-19 (idpf, ice, i40e, ixgbevf, e1000e) For idpf: Li Li moves the check for software marker to occur after incrementing next to clean to avoid re-encountering the same packet. He also adds a couple of checks to prevent NULL pointer dereferences and NULLs rss_key, after free, in error path so that later checks are properly evaluated. Brian Vazquez adjusts IRQ naming to have correlation with netdev naming. Sreedevi removes validation of action type as part of ntuple rule deletion. For ice: Aaron Ma breaks RDMA initialization into two steps and adjusts calls so that VSIs are entirely configured before plugging. Michal Schmidt fixes initialization of loopback VSI to have proper resources allocated to allow for loopback testing to occur. For i40e: Thomas Gleixner fixes a leak of preempt count by replacing get_cpu() with smp_processor_id(). For ixgbevf: Jedrzej adds a check for mailbox version before attempting to call an associated link state call that is supported in that mailbox version. For e1000e: Vitaly clears power gating feature for Panther Lake systems to avoid packet issues. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: e1000e: clear DPG_EN after reset to avoid autonomous power-gating e1000e: introduce new board type for Panther Lake PCH ixgbevf: fix link setup issue i40e: Fix preempt count leak in napi poll tracepoint ice: fix crash in ethtool offline loopback test ice: recap the VSI and QoS info after rebuild idpf: Fix flow rule delete failure due to invalid validation idpf: change IRQ naming to match netdev and ethtool queue numbering idpf: nullify pointers after they are freed idpf: skip deallocating txq group's txqs if it is NULL idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL idpf: increment completion queue next_to_clean in sw marker wait routine ==================== Link: https://patch.msgid.link/20260225211546.1949260-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: mana: Ring doorbell at 4 CQ wraparoundsLong Li
MANA hardware requires at least one doorbell ring every 8 wraparounds of the CQ. The driver rings the doorbell as a form of flow control to inform hardware that CQEs have been consumed. The NAPI poll functions mana_poll_tx_cq() and mana_poll_rx_cq() can poll up to CQE_POLLING_BUFFER (512) completions per call. If the CQ has fewer than 512 entries, a single poll call can process more than 4 wraparounds without ringing the doorbell. The doorbell threshold check also uses ">" instead of ">=", delaying the ring by one extra CQE beyond 4 wraparounds. Combined, these issues can cause the driver to exceed the 8-wraparound hardware limit, leading to missed completions and stalled queues. Fix this by capping the number of CQEs polled per call to 4 wraparounds of the CQ in both TX and RX paths. Also change the doorbell threshold from ">" to ">=" so the doorbell is rung as soon as 4 wraparounds are reached. Cc: stable@vger.kernel.org Fixes: 58a63729c957 ("net: mana: Fix doorbell out of order violation and avoid unnecessary doorbell rings") Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260226192833.1050807-1-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: usb: r8152: add TRENDnet TUC-ET2GValentin Spreckels
The TRENDnet TUC-ET2G is a RTL8156 based usb ethernet adapter. Add its vendor and product IDs. Signed-off-by: Valentin Spreckels <valentin@spreckels.dev> Link: https://patch.msgid.link/20260226195409.7891-2-valentin@spreckels.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: ethernet: litex: use device pointer to simplify code.Inochi Amaoto
As there is already a device pointer in the probe function, replace all "&pdev->dev" pattern with this predefined device pointer. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260227003351.752934-3-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: ethernet: litex: use devm_register_netdev() to register netdevInochi Amaoto
Use devm_register_netdev to avoid unnecessary remove() callback in platform_driver structure. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260227003351.752934-2-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27r8152: Add 2500baseT EEE status/configuration supportBirger Koblitz
The r8152 driver supports the RTL8156, which is a 2.5Gbit Ethernet controller for USB 3.0, for which support is added for configuring and displaying the EEE advertisement status for 2.5GBit connections. The patch also corrects the determination of whether EEE is active to include the 2.5GBit connection status and make the determination dependent not on the desired speed configuration (tp->speed), but on the actual speed used by the controller. For consistency, this is corrected also for the RTL8152/3. This was tested on an Edimax EU-4307 V1.0 USB-Ethernet adapter with RTL8156, and a SECOMP Value 12.99.1115 USB-C 3.1 Ethernet converter with RTL8153. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Link: https://patch.msgid.link/20260224-b4-eee2g5-v2-1-cf5c83df036e@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27vmxnet3: Suppress page allocation warning for massive Rx Data ringAaron Tomlin
The vmxnet3 driver supports an Rx Data ring (rx-mini) to optimise the processing of small packets. The size of this ring's DMA-coherent memory allocation is determined by the product of the primary Rx ring size and the data ring descriptor size: sz = rq->rx_ring[0].size * rq->data_ring.desc_size; When a user configures the maximum supported parameters via ethtool (rx_ring[0].size = 4096, data_ring.desc_size = 2048), the required contiguous memory allocation reaches 8 MB (8,388,608 bytes). In environments lacking Contiguous Memory Allocator (CMA), dma_alloc_coherent() falls back to the standard zone buddy allocator. An 8 MB allocation translates to a page order of 11, which strictly exceeds the default MAX_PAGE_ORDER (10) on most architectures. Consequently, __alloc_pages_noprof() catches the oversize request and triggers a loud kernel warning stack trace: WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) This warning is unnecessary and alarming to system administrators because the vmxnet3 driver already handles this allocation failure gracefully. If dma_alloc_coherent() returns NULL, the driver safely disables the Rx Data ring (adapter->rxdataring_enabled = false) and falls back to standard, streaming DMA packet processing. To resolve this, append the __GFP_NOWARN flag to the dma_alloc_coherent() gfp_mask. This instructs the page allocator to silently fail the allocation if it exceeds order limits or memory is too fragmented, preventing the spurious warning stack trace. Furthermore, enhance the subsequent netdev_err() fallback message to include the requested allocation size. This provides critical debugging context to the administrator (e.g., revealing that an 8 MB allocation was attempted and failed) without making hardcoded assumptions about the state of the system's configurations. Reviewed-by: Jijie Shao <shaojijie@huawei.com> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> Link: https://patch.msgid.link/20260226163121.4045808-1-atomlin@atomlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: ethernet: mtk_eth_soc: avoid writing to ESW registers on MT7628Joris Vaisvila
The MT7628 has a fixed-link PHY and does not expose MAC control registers. Writes to these registers only corrupt the ESW VLAN configuration. This patch explicitly registers no-op phylink_mac_ops for MT7628, as after removing the invalid register accesses, the existing phylink_mac_ops effectively become no-ops. This code was introduced by commit 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support") Signed-off-by: Joris Vaisvila <joey@tinyisr.com> Reviewed-by: Daniel Golle <daniel@makrotpia.org> Reviewed-by: Stefan Roese <stefan.roese@mailbox.org> Link: https://patch.msgid.link/20260226154547.68553-1-joey@tinyisr.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-27net: phy: micrel: Add support for lan9645x internal phyJens Emil Schulz Østergaard
LAN9645X is a family of switch chips with 5 internal copper phys. The internal PHY is based on parts of LAN8832. This is a low-power, single port triple-speed (10BASE-T/100BASE-TX/1000BASE-T) ethernet physical layer transceiver (PHY) that supports transmission and reception of data on standard CAT-5, as well as CAT-5e and CAT-6 Unshielded Twisted Pair (UTP) cables. Add support for the internal PHY of the lan9645x chip family. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260226-phy_micrel_add_support_for_lan9645x_internal_phy-v3-1-1fe82379962b@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling in ↵Chintan Vankar
ALE table In the current implementation, flushing multicast entries in MAC mode incorrectly deletes entries for all ports instead of only the target port, disrupting multicast traffic on other ports. The cause is adding multicast entries by setting only host port bit, and not setting the MAC port bits. Fix this by setting the MAC port's bit in the port mask while adding the multicast entry. Also fix the flush logic to preserve the host port bit during removal of MAC port and free ALE entries when mask contains only host port. Fixes: 5c50a856d550 ("drivers: net: ethernet: cpsw: add multicast address to ALE table") Signed-off-by: Chintan Vankar <c-vankar@ti.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260224181359.2055322-1-c-vankar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: airoha: fix typo in function nameZhengping Zhang
Corrected the typo in the function name from `airhoa_is_lan_gdm_port` to `airoha_is_lan_gdm_port`. This change ensures consistency in the API naming convention. Signed-off-by: Zhengping Zhang <aquapinn@qq.com> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/tencent_E4FD5D6BC0131E617D848896F5F9FCED6E0A@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: atlantic: fix reading SFP module info on some AQC100 cardsTiernan Hubble
Commit 853a2944aaf3 ("net: atlantic: support reading SFP module info") added support for reading SFP module info on AQC100-based cards. However, it only supports reading directly from the controller's hardware registers, and this does not seem to be supported on certain cards, including my TRENDnet TEG-10GECSFP V3. "ethtool -m" times out when reading certain registers, even when I increase the read poll timeout values. The DPDK "atlantic" driver reads module info via firmware calls instead of directly reading the hardware registers, provided that the NIC's firmware version supports it. This change adapts the DPDK firmware call code to the kernel driver. It preserves the old hardware-based module read code as a fallback when the firmware does not support it, to avoid breaking cards that are currently working. Tested on 2 different TRENDnet TEG-10GECSFP V3 cards, both with firmware version 3.1.121 (current at the time of this patch). Both cards correctly reported module info for a passive DAC cable and 2 different 10G optical transceivers. Signed-off-by: Tiernan Hubble <thubble@thubble.ca> Link: https://patch.msgid.link/20260225002026.1754045-1-thubble@thubble.ca Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: macb: add the .pcs_inband_caps() callback for SGMIICharles Perry
In SGMII mode, GEM can work with or without inband autonegotiation. Signed-off-by: Charles Perry <charles.perry@microchip.com> Link: https://patch.msgid.link/20260224202854.112813-4-charles.perry@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: macb: add support for reporting SGMII inband link statusCharles Perry
This makes it possible to use in-band autonegotiation with SGMII. If using a device tree, this can be done by adding the managed = "in-band-status" property to the gem node. Signed-off-by: Charles Perry <charles.perry@microchip.com> Link: https://patch.msgid.link/20260224202854.112813-3-charles.perry@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: macb: fix SGMII with inband aneg disabledCharles Perry
Make it possible to connect a PHY which does not use inband autoneg to a gem MAC using phylink's information. The previous implementation relied on whether or not the link was a fixed-link to disable SGMII autoneg. This commit extend this to all link which are not configured for inband autonegotiation. Signed-off-by: Charles Perry <charles.perry@microchip.com> Link: https://patch.msgid.link/20260224202854.112813-2-charles.perry@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26octeontx2-af: CGX: replace kfree() with rvu_free_bitmap()Bo Sun
mac_to_index_bmap is allocated with rvu_alloc_bitmap(), so free it with rvu_free_bitmap() instead of open-coding kfree(.bmap) to keep the alloc/free API pairing consistent. Signed-off-by: Bo Sun <bo@mboxify.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260225082348.2519131-1-bo@mboxify.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26net: stmmac: ptp: limit n_per_outRussell King (Oracle)
ptp_clock_ops.n_per_out sets the number of PPS outputs, which the PTP subsystem uses to validate userspace input, such as the index number used in a PTP_CLK_REQ_PEROUT request. stmmac_enable() uses this to index the priv->pps array, which is an array of size STMMAC_PPS_MAX. ptp_clock_ops.n_per_out is initialised using priv->dma_cap.pps_out_num, which is a three bit field read from hardware. Documentation that I've checked suggests that values >= 5 are reserved, but that doesn't mean such values won't appear, and if they do, we can overrun the priv->pps array in stmmac_enable(). stmmac_ptp_register() has protection against this in its loop, but it doesn't act to limit ptp_clock_ops.n_per_out. Fix this by introducing a local variable, pps_out_num which is limited to STMMAC_PPS_MAX, and use that when initialising the array and setting priv->ptp_clock_ops.n_per_out. Print a warning when we limit the number of outputs. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vvBhn-0000000ArCg-4C4u@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26wifi: ath11k: fix memory leaks in beacon template setupZilin Guan
The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template") Fixes: 335a92765d30 ("wifi: ath11k: MBSSID beacon support") Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260130084451.110768-1-zilin@seu.edu.cn Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26wifi: ath12k: add basic hwmon temperature reportingMaharaja Kennadyrajan
Add initial thermal support by wiring up a per-radio (pdev) hwmon temperature sensor backed by the existing WMI pdev temperature command and event. When userspace reads the sysfs file temp1_input, the driver sends WMI_PDEV_GET_TEMPERATURE_CMDID (tag WMI_TAG_PDEV_GET_TEMPERATURE_CMD) and waits for the corresponding WMI_PDEV_TEMPERATURE_EVENTID (tag WMI_TAG_PDEV_TEMPERATURE_EVENT) to get the temperature and pdev_id. Export the reported value in millidegrees Celsius as required by hwmon. The temperature reported is per-radio (pdev). In a multi-radio wiphy under a single phy, a separate hwmon device is created for each radio. Sample command and output: $ cat /sys/devices/pci0000:00/.../ieee80211/phyX/hwmonY/temp1_input $ 50000 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Co-developed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260223132622.43464-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26wifi: ath12k: fix indentation in ath12k_qmi_aux_uc_load()Baochen Qiang
Smatch complains: drivers/net/wireless/ath/ath12k/qmi.c:3342 ath12k_qmi_aux_uc_load() warn: inconsistent indenting Fix it. Compile tested only. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602061221.5SCuwKhy-lkp@intel.com/ Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260209-ath12k-fix-indention-v1-1-6b87ae99745e@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26wifi: ath9k: Fix typoAlejandro Colomar
This only worked by chance, because all callers of this macro used the same identifiers that were expected by the macro. $ grep -rn ath_for_each_chanctx drivers/net/wireless/ath/ath9k/main.c:1576: ath_for_each_chanctx(sc, ctx) drivers/net/wireless/ath/ath9k/main.c:2554: ath_for_each_chanctx(sc, ctx) { drivers/net/wireless/ath/ath9k/channel.c:165: ath_for_each_chanctx(sc, ctx) { drivers/net/wireless/ath/ath9k/channel.c:291: ath_for_each_chanctx(sc, ctx) { drivers/net/wireless/ath/ath9k/channel.c:861: ath_for_each_chanctx(sc, ctx) { drivers/net/wireless/ath/ath9k/debug.c:717: ath_for_each_chanctx(sc, ctx) { drivers/net/wireless/ath/ath9k/ath9k.h:446:#define ath_for_each_chanctx(_sc, _ctx) \ Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Toke Høiland-Jørgensen <toke@toke.dk> Cc: <stable+noautosel@kernel.org> # the code worked by chance Fixes: c4dc0d040e35 ("ath9k: Fetch appropriate operating channel context") Signed-off-by: Alejandro Colomar <alx@kernel.org> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/6ab107cf786f9d05dc4d84ea4e2d1b219ce108c0.1766355822.git.alx@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.0-rc2). Conflicts: tools/testing/selftests/drivers/net/hw/rss_ctx.py 19c3a2a81d2b ("selftests: drv-net: rss: Generate unique ports for RSS context tests") ce5a0f4612db ("selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up") include/net/inet_connection_sock.h 858d2a4f67ff6 ("tcp: fix potential race in tcp_v6_syn_recv_sock()") fcd3d039fab69 ("tcp: make tcp_v{4,6}_send_check() static") https://lore.kernel.org/aZ8PSFLzBrEU3I89@sirena.org.uk drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c drivers/net/ethernet/mellanox/mlx5/core/en/xsk/pool.c 69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") bf4afc53b77ae ("Convert 'alloc_obj' family to use the new default GFP_KERNEL argument") 8a96b9144f18a ("net/mlx5e: Alloc xsk channel param out of mlx5e_open_xsk()") Adjacent changes: net/netfilter/ipvs/ip_vs_ctl.c c59bd9e62e06 ("ipvs: use more counters to avoid service lookups") bf4afc53b77a ("Convert 'alloc_obj' family to use the new default GFP_KERNEL argument") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-26Merge tag 'net-7.0-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from IPsec, Bluetooth and netfilter Current release - regressions: - wifi: fix dev_alloc_name() return value check - rds: fix recursive lock in rds_tcp_conn_slots_available Current release - new code bugs: - vsock: lock down child_ns_mode as write-once Previous releases - regressions: - core: - do not pass flow_id to set_rps_cpu() - consume xmit errors of GSO frames - netconsole: avoid OOB reads, msg is not nul-terminated - netfilter: h323: fix OOB read in decode_choice() - tcp: re-enable acceptance of FIN packets when RWIN is 0 - udplite: fix null-ptr-deref in __udp_enqueue_schedule_skb(). - wifi: brcmfmac: fix potential kernel oops when probe fails - phy: register phy led_triggers during probe to avoid AB-BA deadlock - eth: - bnxt_en: fix deleting of Ntuple filters - wan: farsync: fix use-after-free bugs caused by unfinished tasklets - xscale: check for PTP support properly Previous releases - always broken: - tcp: fix potential race in tcp_v6_syn_recv_sock() - kcm: fix zero-frag skb in frag_list on partial sendmsg error - xfrm: - fix race condition in espintcp_close() - always flush state and policy upon NETDEV_UNREGISTER event - bluetooth: - purge error queues in socket destructors - fix response to L2CAP_ECRED_CONN_REQ - eth: - mlx5: - fix circular locking dependency in dump - fix "scheduling while atomic" in IPsec MAC address query - gve: fix incorrect buffer cleanup for QPL - team: avoid NETDEV_CHANGEMTU event when unregistering slave - usb: validate USB endpoints" * tag 'net-7.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits) netfilter: nf_conntrack_h323: fix OOB read in decode_choice() dpaa2-switch: validate num_ifs to prevent out-of-bounds write net: consume xmit errors of GSO frames vsock: document write-once behavior of the child_ns_mode sysctl vsock: lock down child_ns_mode as write-once selftests/vsock: change tests to respect write-once child ns mode net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query net/mlx5: Fix missing devlink lock in SRIOV enable error path net/mlx5: E-switch, Clear legacy flag when moving to switchdev net/mlx5: LAG, disable MPESW in lag_disable_change() net/mlx5: DR, Fix circular locking dependency in dump selftests: team: Add a reference count leak test team: avoid NETDEV_CHANGEMTU event when unregistering slave net: mana: Fix double destroy_workqueue on service rescan PCI path MAINTAINERS: Update maintainer entry for QUALCOMM ETHQOS ETHERNET DRIVER dpll: zl3073x: Remove redundant cleanup in devm_dpll_init() selftests/net: packetdrill: Verify acceptance of FIN packets when RWIN is 0 tcp: re-enable acceptance of FIN packets when RWIN is 0 vsock: Use container_of() to get net namespace in sysctl handlers net: usb: kaweth: validate USB endpoints ...
2026-02-26wifi: ath12k: fix station lookup failure when disconnecting from APBaochen Qiang
In ath12k_wmi_tlv_fw_stats_data_parse() and ath12k_wmi_tlv_rssi_chain_parse(), the driver uses ieee80211_find_sta_by_ifaddr() to look up the station associated with the incoming firmware statistics. This works under normal conditions but fails during AP disconnection, resulting in log messages like: wlan0: deauthenticating from xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING) wlan0: moving STA xxxxxx to state 3 wlan0: moving STA xxxxxx to state 2 wlan0: moving STA xxxxxx to state 1 ath12k_pci 0000:02:00.0: not found station bssid xxxxxx for vdev stat ath12k_pci 0000:02:00.0: not found station of bssid xxxxxx for rssi chain ath12k_pci 0000:02:00.0: failed to pull fw stats: -71 ath12k_pci 0000:02:00.0: time out while waiting for get fw stats wlan0: Removed STA xxxxxx wlan0: Destroyed STA xxxxxx The failure happens because the station has already been removed from ieee80211_local::sta_hash by the time firmware statistics are requested through drv_sta_statistics(). Switch the lookup to ath12k_link_sta_find_by_addr(), which searches the driver's link station hash table that still has the station recorded at that time. This also implicitly fixes another issue: the current code always uses deflink regardless of which link the statistics belong to, which is incorrect in MLO scenarios. The new helper returns the correct link station. Additionally, raise the log level on lookup failures. With the updated helper, such failures should no longer occur under normal conditions. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 79e7b04b5388 ("wifi: ath12k: report station mode signal strength") Fixes: 6af5bc381b36 ("wifi: ath12k: report station mode per-chain signal strength") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260129-ath12k-fw-stats-fixes-v1-2-55d66064f4d5@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26wifi: ath12k: use correct pdev id when requesting firmware statsBaochen Qiang
To get firmware statistics, currently ar->pdev->pdev_id is passed as an argument to ath12k_mac_get_fw_stats() in ath12k_mac_op_sta_statistics(). For single pdev device like WCN7850, its value is 0 which represents the SoC pdev id. As a result, WCN7850 firmware sends the same reply to host twice, which further results in memory leak: unreferenced object 0xffff88812e286000 (size 192): comm "softirq", pid 0, jiffies 4294981997 hex dump (first 32 bytes): 10 a5 40 11 81 88 ff ff 10 a5 40 11 81 88 ff ff ..@.......@..... 00 00 00 00 00 00 00 00 80 ff ff ff 33 05 00 00 ............3... backtrace (crc cecc8c82): __kmalloc_cache_noprof ath12k_wmi_tlv_fw_stats_parse ath12k_wmi_tlv_iter ath12k_wmi_op_rx ath12k_htc_rx_completion_handler ath12k_ce_per_engine_service ath12k_pci_ce_workqueue process_one_work bh_worker tasklet_action handle_softirqs Detailed explanation is: 1. ath12k_mac_get_fw_stats() called in ath12k_mac_op_sta_statistics() to get vdev statistics, making the caller thread wait. 2. firmware sends the first reply, ath12k_wmi_tlv_fw_stats_data_parse() allocates buffers to cache necessary information. Following that, in ath12k_wmi_fw_stats_process() if events of all started vdev haved been received, is_end flag is set hence the waiting thread gets waken up by the ar->fw_stats_done/->fw_stats_complete signals. 3. ath12k_mac_get_fw_stats() wakes up and returns successfully. ath12k_mac_op_sta_statistics() saves required parameters and calls ath12k_fw_stats_reset() to free buffers allocated earlier. 4. firmware sends the second reply. As usual, buffers are allocated and attached to the ar->fw_stats.vdevs list. Note this time there is no thread waiting, therefore no chance to free those buffers. 5. ath12k module gets unloaded. If there has been no more firmware statistics request made since step 4, or if the request fails (see the example in the following patch), there is no chance to call ath12k_fw_stats_reset(). Consequently those buffers leak. Actually for single pdev device, using SoC pdev id in ath12k_mac_op_sta_statistics() is wrong, because the purpose is to get statistics of a specific station, which is mapped to a specific pdev. That said, the id of actual individual pdev should be fetched and used instead. The helper ath12k_mac_get_target_pdev_id() serves for this purpose, hence use it to fix this issue. Note it also works for other devices as well due to the single_pdev_only check inside. The same applies to ath12k_mac_op_get_txpower() and ath12k_mac_op_link_sta_statistics() as well. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: 79e7b04b5388 ("wifi: ath12k: report station mode signal strength") Fixes: e92c658b056b ("wifi: ath12k: add get_txpower mac ops") Fixes: ebebe66ec208 ("wifi: ath12k: fill link station statistics for MLO") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260129-ath12k-fw-stats-fixes-v1-1-55d66064f4d5@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-02-26dpaa2-switch: validate num_ifs to prevent out-of-bounds writeJunrui Luo
The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes() but never validates it against DPSW_MAX_IF (64). This value controls iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices into the fixed-size cfg->if_id[DPSW_MAX_IF] array. When firmware reports num_ifs >= 64, the loop can write past the array bounds. Add a bound check for num_ifs in dpaa2_switch_init(). dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all ports match the flood filter, the loop fills all 64 slots and the control interface write overflows by one entry. The check uses >= because num_ifs == DPSW_MAX_IF is also functionally broken. build_if_id_bitmap() silently drops any ID >= 64: if (id[i] < DPSW_MAX_IF) bmap[id[i] / 64] |= ... Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains") Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26bonding: print churn state via netlinkHangbin Liu
Currently, the churn state is printed only in sysfs. Add netlink support so users could get the state via netlink. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20260224020215.6012-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26pppoe: remove kernel-mode relay supportQingfang Deng
The kernel-mode PPPoE relay feature and its two associated ioctls (PPPOEIOCSFWD and PPPOEIOCDFWD) are not used by any existing userspace PPPoE implementations. The most commonly-used package, RP-PPPoE [1], handles the relaying entirely in userspace. This legacy code has remained in the driver since its introduction in kernel 2.3.99-pre7 for over two decades, but has served no practical purpose. Remove the unused relay code. [1] https://dianne.skoll.ca/projects/rp-pppoe/ Signed-off-by: Qingfang Deng <dqfext@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Guillaume Nault <gnault@redhat.com> Link: https://patch.msgid.link/20260224015053.42472-1-dqfext@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: SHAMPO, Allow high order pages in zerocopy modeDragos Tatulea
Allow high order pages only when SHAMPO mode is enabled (hw-gro) and the queue is used for zerocopy (has memory provider ops set). The limit is 128K and it was chosen for the following reasons: - 256K size requires a special case during MTT calculation to split the page in two. That's because two MTTs are needed to form an octword. - Higher sizes require increasing WQE size and/or reducing the number of WQEs. - Having the RQ lined with too few large pages can lead to refill issues. Results show an increase in BW and a decrease in CPU usage. The benchmark was done with the zcrx samples from liburing [0]. rx_buf_len=4K, oncpu [1]: packets=3358832 (MB=820027), rps=55794 (MB/s=13621) Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 9 1.56 0.00 18.09 13.42 0.00 66.80 0.00 0.00 0.00 0.12 rx_buf_len=128K, oncpu [2]: packets=3781376 (MB=923187), rps=62813 (MB/s=15335) Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 9 0.33 0.00 7.61 18.86 0.00 73.08 0.00 0.00 0.00 0.12 rx_buf_len=4K, offcpu [3]: packets=3460368 (MB=844816), rps=57481 (MB/s=14033) Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 9 0.00 0.00 0.26 0.00 0.00 92.63 0.00 0.00 0.00 7.11 Average: 11 3.04 0.00 68.09 28.87 0.00 0.00 0.00 0.00 0.00 0.00 rx_buf_len=128K, offcpu [4]: packets=4119840 (MB=1005820), rps=68435 (MB/s=16707) Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 9 0.00 0.00 0.87 0.00 0.00 63.77 0.00 0.00 0.00 35.36 Average: 11 1.96 0.00 43.68 54.37 0.00 0.00 0.00 0.00 0.00 0.00 [0] https://github.com/isilence/liburing/tree/zcrx/rx-buf-len [1] commands: $> taskset -c 9 ./zcrx 6 -i eth2 -q 9 -A 1 -B 4096 -S 33554432 $> ./send-zerocopy tcp -6 -D 2001:db8::1 -t 60 -C 0 -l 1 -b 1 -n 1 -z 1 -d -s 256000 [2] commands: $> taskset -c 9 ./zcrx 6 -i eth2 -q 9 -A 1 -B 131072 -S 33554432 $> ./send-zerocopy tcp -6 -D 2001:db8::1 -t 60 -C 0 -l 1 -b 1 -n 1 -z 1 -d -s 256000 [3] commands: $> taskset -c 11 ./zcrx 6 -i eth2 -q 9 -A 1 -B 4096 -S 33554432 $> ./send-zerocopy tcp -6 -D 2001:db8::1 -t 60 -C 0 -l 1 -b 1 -n 1 -z 1 -d -s 256000 [4] commands: $> taskset -c 11 ./zcrx 6 -i eth2 -q 9 -A 1 -B 131072 -S 33554432 $> ./send-zerocopy tcp -6 -D 2001:db8::1 -t 60 -C 0 -l 1 -b 1 -n 1 -z 1 -d -s 256000 Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-16-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Add param helper to calculate max page sizeDragos Tatulea
This function will be necessary to determine the upper limit of rx-page-size. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-15-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Pass netdev queue config to param calculationsDragos Tatulea
If set, take rx_page_size into consideration when calculating the page shift in Multi Packet WQE mode. The queue config is saved in the mlx5e_rq_opt_param struct which is added to the mlx5e_channel_param struct. Now the configuration can be read from the struct instead of adding it as an argument to all call sites. For consistency, the queue config is assigned in mlx5e_build_channel_param(). The queue configuration is read only from queue management ops as that's the only place where it is currently useful. Furthermore, netdev_queue_config() expects netdev->queue_mgmt_ops to be set which is not always the case (representor netdevs). Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-14-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Add queue config ops for page sizeDragos Tatulea
For now allow only PAGE_SIZE. A subsequent patch will add support for high order pages in zero-copy mode. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-13-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: RX, Make page frag bias more robustDragos Tatulea
The formula uses the system page size but does not account for high order pages. One way to fix this would be to adapt the formula to take into account the pool order. This would require calculating it for every allocation or adding an additional rq struct member to hold the bias max. However, the above is not really needed as the driver doesn't check the bias value. It has other means to calculate the expected number of fragments based on context. This patch simply sets the value to the max possible value. A sanity check is added during queue init phase to avoid having really big pages from using more fragments than the type can fit. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-12-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Alloc rq drop page based on calculated page_shiftDragos Tatulea
An upcoming patch will allow setting the page order for RX pages to be greater than 0. Make sure that the drop page will also be allocated with the right size when that happens. Take extra care when calculating the drop page size to account for page_shift < PAGE_SHIFT which can happen for xsk. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-11-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Set page_pool order based on calculated page_shiftDragos Tatulea
Instead of unconditionally setting the page_pool to 0, calculate it from page_shift for MPWQE case. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-10-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: SHAMPO, Always calculate page sizeDragos Tatulea
Adapt the rx path in SHAMPO mode to calculate page size based on configured page_shift when dealing with payload data. This is necessary as an upcoming patch will add support for using different page sizes. This change has no functional changes. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-9-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Drop unused channel parametersDragos Tatulea
The channel parameters from struct mlx5_qmgmt_data are built in mlx5e_queue_mem_alloc() but are not used. mlx5e_open_channel() builds the channel parameters internally and those parameters will be the ones that are used when opening the queue. This patch drops the unused parameters. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-8-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Move xsk param into new option container structDragos Tatulea
The xsk parameter configuration (struct mlx5e_xsk_param) is passed around many places during parameter calculation. It is used to contain channel specific information (as opposed to the global info from struct mlx5e_params). Upcoming changes will need to push similar channel specific rq configuration. Instead of adding one more parameter to all these functions, create a new container structure that has optional rq specific parameters. The xsk parameter will be the first of such kind. The new container struct is itself optional. That means that before checking its members, it has to be checked itself for validity. This patch has no functional changes. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-7-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Alloc xsk channel param out of mlx5e_open_xsk()Dragos Tatulea
Currently the allocation and filling of the xsk channel parameters was done in mlx5e_open_xsk(). Move this responsibility out of mlx5e_open_xsk() and have the function take an already filled mlx5e_channel_param. mlx5e_open_channel() already allocates channel parameters. The only precaution that is needed is to call mlx5e_build_xsk_channel_param() before mlx5e_open_xsk(). mlx5e_xsk_enable_locked() now allocates and fills the xsk parameters. For simplicity, link the xsk parameters in struct mlx5e_channel_params so that channel params can be passed around. This patch has no functional changes. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-6-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Expose and rename xsk channel parameter functionDragos Tatulea
mlx5e_build_xsk_cparam() is meant to be the alternative to mlx5e_build_channel_param(). It calculates only the parameters that it requires using the previously configured mlx5e_xsk_param. Move this function to params.c to be alongside mlx5e_build_channel_param() and give it a similar name. Expose the function as it will be needed by upcoming changes. This patch has no functional changes. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-5-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Extract max_xsk_wqebbs into its own functionDragos Tatulea
Calculating max_xsk_wqebbs seems large enough to deserve its own function. It will make upcoming changes easier. This patch has no functional changes. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-4-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Extract striding rq param calculation in functionDragos Tatulea
Calculating parameters for striding rq is large enough to deserve its own function. As the names are also very long it is very easy to hit on the 80 char limitation every time a change is made. This is an additional sign that it should be extracted into its own function. This patch has no functional change. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-3-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-26net/mlx5e: Make mlx5e_rq_param naming consistentDragos Tatulea
This structure is used under different names: rq_param, rq_params, param, rqp. Refactor the code to use a single name: rq_param. This patch has no functional change. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260223204155.1783580-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-16 04:05:28 +0000