summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-17tcp: move tcp_rate_skb_sent() to tcp_output.cEric Dumazet
It is only called from __tcp_transmit_skb() and __tcp_retransmit_skb(). Move it in tcp_output.c and make it static. clang compiler is now able to inline it from __tcp_transmit_skb(). gcc compiler inlines it in the two callers, which is also fine. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260114165109.1747722-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17net: ethernet: ti: cpsw_ale: Remove obsolete macrosStefan Wiehler
- ALE_VERSION_MAJOR/MINOR are no longer used following the transition to regmaps in commit bbfc7e2b9ebe ("net: ethernet: ti: cpsw_ale: use regfields for ALE registers") - ALE_VERSION_IR3 is unused since entry mask bits are no longer hardcoded with commit b5d31f294027 ("net: ethernet: ti: ale: optimize ale entry mask bits configuartion") - ALE_VERSION_IR4 has never been used since its introduction in commit ca47130a744b ("net: netcp: ale: update to support unknown vlan controls for NU switch") Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com> Link: https://patch.msgid.link/20260114144425.3973272-1-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17net/sched: cake: avoid separate allocation of struct cake_sched_configToke Høiland-Jørgensen
Paolo pointed out that we can avoid separately allocating struct cake_sched_config even in the non-mq case, by embedding it into struct cake_sched_data. This reduces the complexity of the logic that swaps the pointers and frees the old value, at the cost of adding 56 bytes to the latter. Since cake_sched_data is already almost 17k bytes, this seems like a reasonable tradeoff. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Fixes: bc0ce2bad36c ("net/sched: sch_cake: Factor out config variables into separate struct") Link: https://patch.msgid.link/20260113143157.2581680-1-toke@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17docs: tls: Enhance TLS resync async process documentationShahar Shitrit
Expand the tls-offload.rst documentation to provide a more detailed explanation of the asynchronous resync process, including the role of struct tls_offload_resync_async in managing resync requests on the kernel side. Also, add documentation for helper functions tls_offload_rx_resync_async_request_start/ _end/ _cancel. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1768298883-1602599-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17Merge branch 'uapi-use-uapi-definitions-of-int_max-and-int_min'Jakub Kicinski
Thomas Weißschuh says: ==================== uapi: Use UAPI definitions of INT_MAX and INT_MIN Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a dependency on a libc, which UAPI headers should not do. Introduce and use equivalent UAPI constants. ==================== Link: https://patch.msgid.link/20260113-uapi-limits-v2-0-93c20f4b2c1a@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17netfilter: uapi: Use UAPI definition of INT_MAX and INT_MINThomas Weißschuh
Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a dependency on a libc, which UAPI headers should not do. Use the equivalent UAPI constants. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260113-uapi-limits-v2-3-93c20f4b2c1a@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17ethtool: uapi: Use UAPI definition of INT_MAXThomas Weißschuh
Using <limits.h> to gain access to INT_MAX introduces a dependency on a libc, which UAPI headers should not do. Use the equivalent UAPI constant. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260113-uapi-limits-v2-2-93c20f4b2c1a@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17uapi: add INT_MAX and INT_MIN constantsThomas Weißschuh
Some UAPI headers use INT_MAX and INT_MIN. Currently they include <limits.h> for their definitions, which introduces a problematic dependency on libc. Add custom, namespaced definitions of INT_MAX and INT_MIN using the same values as the regular kernel code. These definitions are not added to uapi/linux/limits.h, as that header will conflict with libc definitions on some platforms. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260113-uapi-limits-v2-1-93c20f4b2c1a@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17net: usb: sr9700: remove code to drive nonexistent MIIEthan Nelson-Moore
This device does not have a MII, even though the driver contains code to drive one (because it originated as a copy of the dm9601 driver). It also only supports 10Mbps half-duplex operation (the DM9601 registers to set the speed/duplex mode are read-only). Remove all MII-related code and implement sr9700_get_link_ksettings which returns hardcoded correct information for the link speed and duplex mode. Also add announcement of the link status like many other Ethernet drivers have. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260113040649.54248-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17Merge branch 'net-pcs-rzn1-miic-support-configurable-phy_link-polarity'Jakub Kicinski
Lad Prabhakar says: ==================== net: pcs: rzn1-miic: Support configurable PHY_LINK polarity This series adds support for configuring the active level of MIIC PHY_LINK status signals on Renesas RZ/N1 and RZ/T2H/N2H platforms. The MIIC block provides dedicated hardware PHY_LINK signals that indicate EtherPHY link-up and link-down status independently of whether the MAC (GMAC) or Ethernet switch (ETHSW) is used. While GMAC-based systems typically obtain link state via MDIO and handle it in software, the ETHSW relies on these PHY_LINK pins for both CPU-assisted operation and switch-only forwarding paths that do not involve the host processor. These hardware PHY_LINK signals are particularly important for use cases requiring fast reaction to link-down events, such as redundancy protocols including Device Level Ring (DLR). In such scenarios, relying solely on software-based link detection introduces latency that can negatively impact recovery time. The ETHSW therefore exposes PHY_LINK signals to enable immediate hardware-level detection of cable or port failures. Some systems require the PHY_LINK signal polarity to be configured as active low rather than the default active high. This series introduces a new DT property to describe the required polarity and adds corresponding driver support to program the MIIC PHY_LINK register accordingly. The configuration is accumulated during DT parsing and applied once hardware initialization is complete, taking into account SoC-specific differences between RZ/N1 and RZ/T2H/N2H. ==================== Link: https://patch.msgid.link/20260112173555.1166714-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17net: pcs: rzn1-miic: Add PHY_LINK active-level configuration supportLad Prabhakar
Add support to configure the active level of MIIC PHY_LINK status signals on a per-converter basis using a DT property. MIIC provides dedicated PHY_LINK signals that indicate EtherPHY link-up and link-down status in hardware. These signals are required regardless of whether GMAC or ETHSW is used. With GMAC, link state is retrieved via MDC/MDIO and handled in software, while ETHSW relies on PHY_LINK pins for both CPU-assisted operation and switch-only data paths that do not involve the host. Hardware PHY_LINK signals are also critical for fast reaction to link-down events, for example when running redundancy protocols such as Device Level Ring (DLR), where rapid detection of cable faults is required to switch to an alternate path without software latency. Parse the requested polarity from DT, accumulate the configuration during probing, and apply it to the MIIC_PHY_LINK register once hardware initialization is complete, when the registers can be safely modified. Handle SoC-specific bit layout differences between RZ/N1 and RZ/T2H/N2H within the driver. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260112173555.1166714-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17dt-bindings: net: pcs: renesas,rzn1-miic: Add phy_link propertyLad Prabhakar
Add the renesas,miic-phy-link-active-low property to allow configuring the active level of phy_link status signals provided by the MIIC block. EtherPHY link-up and link-down status is required as a hardware IP feature independent of whether GMAC or ETHSW is used. With GMAC, link state is retrieved via MDC/MDIO and handled in software. In contrast, ETHSW exposes dedicated PHY_LINK pins that provide this information directly in hardware. These PHY_LINK signals are required not only for host-controlled traffic but also for switch-only forwarding paths where frames are exchanged between external nodes without CPU involvement. This is particularly important for redundancy protocols such as DLR (Device Level Ring), which depend on fast detection of link-down events caused by cable or port failures. Handling such events purely in software introduces latency, which is why ETHSW provides dedicated hardware PHY_LINK pins. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260112173555.1166714-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-17mctp i2c: initialise event handler read bytesMatt Johnston
Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads will return "val" from the i2c bus driver. For i2c-aspeed and i2c-npcm7xx that is a stack uninitialised u8. Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c instance, now it returns all 0xff. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20260113-mctp-read-fix-v1-1-70c4b59c741c@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15xgbe: Use netlink extack to report errors to ethtoolVishal Badole
Upgrade XGBE driver to report errors via netlink extack instead of netdev_error so ethtool userspace can be aware of failures. Signed-off-by: Vishal Badole <Vishal.Badole@amd.com> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20260114080357.1778132-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15bnxt_en: Fix build break on non-x86 platformsPavan Chebbi
Commit c470195b989fe added .getcrosststamp() interface where the code uses boot_cpu_has() function which is available only in x86 platforms. This fails the build on any other platform. Since the interface is going to be supported only on x86 anyway, we can simply compile out the entire support on non-x86 platforms. Cover the .getcrosststamp support under CONFIG_X86 Fixes: c470195b989f ("bnxt_en: Add PTP .getcrosststamp() interface to get device/host times") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601111808.WnBJCuWI-lkp@intel.com Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260113183422.508851-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15hinic3: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
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") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. 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. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/20260113151433.257320-1-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: phy: realtek: fix in-band capabilities for 2.5G PHYsJan Hoffmann
It looks like the configuration of in-band AN only affects SGMII, and it is always disabled for 2500Base-X. Adjust the reported capabilities accordingly. This is based on testing using OpenWrt on Zyxel XGS1010-12 rev A1 with RTL8226-CG, and Zyxel XGS1210-12 rev B1 with RTL8221B-VB-CG. On these devices, 2500Base-X in-band AN is known to work with some SFP modules (containing an unknown PHY). However, with the built-in Realtek PHYs, no auto-negotiation takes place, irrespective of the configuration of the PHY. Fixes: 10fbd71fc5f9b ("net: phy: realtek: implement configuring in-band an") Signed-off-by: Jan Hoffmann <jan@3e8.eu> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20260113205557.503409-1-jan@3e8.eu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: minor __alloc_skb() optimizationEric Dumazet
We can directly call __finalize_skb_around() instead of __build_skb_around() because @size is not zero. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260113131017.2310584-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: phy: remove unused fixup unregistering functionsHeiner Kallweit
No user of PHY fixups unregisters these. IOW: The fixup unregistering functions are unused and can be removed. Remove also documentation for these functions. Whilst at it, remove also mentioning of phy_register_fixup() from the Documentation, as this function has been static since ea47e70e476f ("net: phy: remove fixup-related definitions from phy.h which are not used outside phylib"). Fixup unregistering functions were added with f38e7a32ee4f ("phy: add phy fixup unregister functions") in 2016, and last user was removed with 6782d06a47ad ("net: usb: lan78xx: Remove KSZ9031 PHY fixup") in 2024. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/ff8ac321-435c-48d0-b376-fbca80c0c22e@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: usb: sr9700: fix byte numbering in commentsEthan Nelson-Moore
The comments describing the RX/TX headers and status response use a combination of 0- and 1-based indexing, leading to confusion. Correct the numbering and make it consistent. Also fix a typo "pm" for "pn". This issue also existed in dm9601 and was fixed in commit 61189c78bda8 ("dm9601: trivial comment fixes"). Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Peter Korsgaard <peter@korsgaard.com> Link: https://patch.msgid.link/20260113075327.85435-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: ethernet: dnet: remove driverHeiner Kallweit
This legacy platform driver was used with some Qong board. Support for this board was removed with commit c93197b0041d ("ARM: imx: Remove i.MX31 board files") in 2020. So remove this now orphaned driver. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/cef7c728-28ee-439f-b747-eb1c9394fe51@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15Merge branch 'net-airoha-init-block-ack-memory-region-for-mt7996-npu-offloading'Jakub Kicinski
Lorenzo Bianconi says: ==================== net: airoha: Init Block Ack memory region for MT7996 NPU offloading This is a preliminary series in order to enable NPU offloading for MT7996 (Eagle) chipset. ==================== Link: https://patch.msgid.link/20260108-airoha-ba-memory-region-v3-0-bf1814e5dcc4@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: airoha: npu: Init BA memory region if provided via DTSLorenzo Bianconi
Initialize NPU Block Ack memory region if reserved via DTS. Block Ack memory region is used by NPU MT7996 (Eagle) offloading. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260108-airoha-ba-memory-region-v3-2-bf1814e5dcc4@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15dt-bindings: net: airoha: npu: Add BA memory regionLorenzo Bianconi
Introduce Block Ack memory region used by NPU MT7996 (Eagle) offloading. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108-airoha-ba-memory-region-v3-1-bf1814e5dcc4@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15Merge branch 'net-phy-adin-enable-configuration-of-the-lp-termination-register'Jakub Kicinski
Osose Itua says: ==================== net: phy: adin: enable configuration of the LP Termination Register ==================== Link: https://patch.msgid.link/20260107221913.1334157-1-osose.itua@savoirfairelinux.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15net: phy: adin: enable configuration of the LP Termination RegisterOsose Itua
The ADIN1200/ADIN1300 provide a control bit that selects between normal receive termination and the lowest common mode impedance for 100BASE-TX operation. This behavior is controlled through the Low Power Termination register (B_100_ZPTM_EN_DIMRX). Bit 0 of this register enables normal termination when set (this is the default), and selects the lowest common mode impedance when cleared. Signed-off-by: Osose Itua <osose.itua@savoirfairelinux.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20260107221913.1334157-3-osose.itua@savoirfairelinux.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15dt-bindings: net: adi,adin: document LP Termination propertyOsose Itua
Add "adi,low-cmode-impedance" boolean property which, when present, configures the PHY for the lowest common-mode impedance on the receive pair for 100BASE-TX operation by clearing the B_100_ZPTM_EN_DIMRX bit. This is suited for capacitive coupled applications and other applications where there may be a path for high common-mode noise to reach the PHY. If this value is not present, the value of the bit by default is 1, which is normal termination (zero-power termination) mode. Signed-off-by: Osose Itua <osose.itua@savoirfairelinux.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20260107221913.1334157-2-osose.itua@savoirfairelinux.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15Merge tag 'phy_common_properties' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Vinod Koul says: ==================== phy common properties Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests (from Vladimir Oltean). * tag 'phy_common_properties' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: add phy_get_rx_polarity() and phy_get_tx_polarity() dt-bindings: phy-common-props: RX and TX lane polarity inversion dt-bindings: phy-common-props: ensure protocol-names are unique dt-bindings: phy-common-props: create a reusable "protocol-names" definition dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml ==================== Link: https://patch.msgid.link/aWeXvFcGNK5T6As9@vaman Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15ethtool: Clarify len/n_stats fields in/out semanticsGal Pressman
Document that the 'len' field in ethtool_gstrings and 'n_stats' field in ethtool_stats optionally serve dual purposes: on entry they specify the number of items requested, and on return they indicate the number actually returned (which is not necessarily the same). Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Link: https://patch.msgid.link/20260115060544.481550-1-gal@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.19-rc6). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-15Merge tag 'net-6.19-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth, can and IPsec. Current release - regressions: - net: add net.core.qdisc_max_burst - can: propagate CAN device capabilities via ml_priv Previous releases - regressions: - dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list() - ipv6: fix use-after-free in inet6_addr_del(). - xfrm: fix inner mode lookup in tunnel mode GSO segmentation - ip_tunnel: spread netdev_lockdep_set_classes() - ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() - bluetooth: hci_sync: enable PA sync lost event - eth: virtio-net: - fix the deadlock when disabling rx NAPI - fix misalignment bug in struct virtnet_info Previous releases - always broken: - ipv4: ip_gre: make ipgre_header() robust - can: fix SSP_SRC in cases when bit-rate is higher than 1 MBit. - eth: - mlx5e: profile change fix - octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback - macvlan: fix possible UAF in macvlan_forward_source()" * tag 'net-6.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (37 commits) virtio_net: Fix misalignment bug in struct virtnet_info net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts can: raw: instantly reject disabled CAN frames can: propagate CAN device capabilities via ml_priv Revert "can: raw: instantly reject unsupported CAN frames" net/sched: sch_qfq: do not free existing class in qfq_change_class() selftests: drv-net: fix RPS mask handling for high CPU numbers selftests: drv-net: fix RPS mask handling in toeplitz test ipv6: Fix use-after-free in inet6_addr_del(). dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list() net: hv_netvsc: reject RSS hash key programming without RX indirection table tools: ynl: render event op docs correctly net: add net.core.qdisc_max_burst net: airoha: Fix typo in airoha_ppe_setup_tc_block_cb definition net: phy: motorcomm: fix duplex setting error for phy leds net: octeon_ep_vf: fix free_irq dev_id mismatch in IRQ rollback net/mlx5e: Restore destroying state bit after profile cleanup net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv net/mlx5e: Fix crash on profile change rollback failure ...
2026-01-15Merge tag 'linux-can-fixes-for-6.19-20260115' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-01-15 this is a pull request of 4 patches for net/main, it super-seeds the "can 2026-01-14" pull request. The dev refcount leak in patch #3 is fixed. The first 3 patches are by Oliver Hartkopp and revert the approach to instantly reject unsupported CAN frames introduced in net-next-for-v6.19 and replace it by placing the needed data into the CAN specific ml_priv. The last patch is by Tetsuo Handa and fixes a J1939 refcount leak for j1939_session in session deactivation upon receiving the second RTS. linux-can-fixes-for-6.19-20260115 * tag 'linux-can-fixes-for-6.19-20260115' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts can: raw: instantly reject disabled CAN frames can: propagate CAN device capabilities via ml_priv Revert "can: raw: instantly reject unsupported CAN frames" ==================== Link: https://patch.msgid.link/20260115090603.1124860-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15Merge tag 'ipsec-2026-01-14' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2026-01-14 1) Fix inner mode lookup in tunnel mode GSO segmentation. The protocol was taken from the wrong field. 2) Set ipv4 no_pmtu_disc flag only on output SAs. The insertation of input SAs can fail if no_pmtu_disc is set. Please pull or let me know if there are problems. ipsec-2026-01-14 * tag 'ipsec-2026-01-14' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: set ipv4 no_pmtu_disc flag only on output sa when direction is set xfrm: Fix inner mode lookup in tunnel mode GSO segmentation ==================== Link: https://patch.msgid.link/20260114121817.1106134-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: inline napi_skb_cache_get()Eric Dumazet
clang is inlining it already, gcc (14.2) does not. Small space cost (215 bytes on x86_64) but faster sk_buff allocations. $ scripts/bloat-o-meter -t net/core/skbuff.gcc.before.o net/core/skbuff.gcc.after.o add/remove: 0/1 grow/shrink: 4/1 up/down: 359/-144 (215) Function old new delta __alloc_skb 471 611 +140 napi_build_skb 245 363 +118 napi_alloc_skb 331 416 +85 skb_copy_ubufs 1869 1885 +16 skb_shift 1445 1413 -32 napi_skb_cache_get 112 - -112 Total: Before=59941, After=60156, chg +0.36% Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260112131515.4051589-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15Merge branch 'net-mlx5-hws-single-flow-counter-support'Paolo Abeni
Tariq Toukan says: ==================== net/mlx5: HWS single flow counter support This small series refactors the flow counter bulk initialization code and extends it so that single flow counters are also usable by hardware steering (HWS) rules. Patches 1-2 refactor the bulk init path: first by factoring out common flow counter bulk initialization into mlx5_fc_bulk_init(), then by splitting the bitmap allocation into mlx5_fs_bulk_bitmap_alloc(), with no functional changes. Patch 3 initializes bulk data for counters allocated via mlx5_fc_single_alloc(), so they can be safely used by HWS rules. ==================== Link: https://patch.msgid.link/1768210825-1598472-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: Initialize bulk for single flow countersMoshe Shemesh
Ensure that flow counters allocated with mlx5_fc_single_alloc() have bulk correctly initialized so they can safely be used in HWS rules. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-4-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: fs, split bulk initMark Bloch
Refactor mlx5_fs_bulk_init() by moving bitmap allocation logic into a new helper function mlx5_fs_bulk_bitmap_alloc(). This change does not alter any logic. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-3-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5: fs, factor out flow counter bulk initMark Bloch
Add mlx5_fc_bulk_init() to handle bulk initialization of flow counters. This change does not alter any logic, but refactors the code to remove duplicate initialization logic by centralizing it in a single function. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768210825-1598472-2-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15Merge branch 'introduce-and-use-netif_xmit_timeout_ms-helper'Paolo Abeni
Tariq Toukan says: ==================== Introduce and use netif_xmit_timeout_ms() helper This is V2, find V1 here: https://lore.kernel.org/all/1764054776-1308696-1-git-send-email-tariqt@nvidia.com/ This series by Shahar introduces a new helper function netif_xmit_timeout_ms() to check if a TX queue has timed out and report the timeout duration. It also encapsulates the check for whether the TX queue is stopped. Replace duplicated open-coded timeout check in hns3 driver with the new helper. For mlx5e, refine the TX timeout recovery flow to act only on SQs whose transmit timestamp indicates an actual timeout, as determined by the helper. This prevents unnecessary channel reopen events caused by attempting recovery on queues that are merely stopped but not truly timed out. ==================== Link: https://patch.msgid.link/1768209383-1546791-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net/mlx5e: Refine TX timeout handling to skip non-timed-out SQShahar Shitrit
mlx5e_tx_timeout_work() is invoked when the dev_watchdog reports a timed-out TX queue. Currently, the recovery flow is triggered for all stopped SQs, which is not always correct — some SQs may be temporarily stopped without actually timing out. Attempting to recover such SQs results in no EQE being polled (since no real timeout occurred), which the driver misinterprets as a recovery failure, unnecessarily causing channel reopening. Improve the logic to initiate recovery only for SQs that are both stopped and timed out. Utilize the helper introduced in the previous patch to determine whether the netdevice watchdog timeout period has elapsed since the SQ’s last transmit timestamp. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768209383-1546791-4-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: hns3: Use netif_xmit_timeout_ms() helperShahar Shitrit
Replace the open-coded TX queue timeout check in hns3_get_timeout_queue() with a call to netif_xmit_timeout_ms() helper. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/1768209383-1546791-3-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: Introduce netif_xmit_timeout_ms() helperShahar Shitrit
Introduce a new helper function netif_xmit_timeout_ms() to check if a TX queue is stopped and has timed out and report the timeout duration. This makes the timeout logic reusable, and will be used in several places in subsequent patches. Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1768209383-1546791-2-git-send-email-tariqt@nvidia.com Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15virtio_net: Fix misalignment bug in struct virtnet_infoGustavo A. R. Silva
Use the new TRAILING_OVERLAP() helper to fix a misalignment bug along with the following warning: drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] This helper creates a union between a flexible-array member (FAM) and a set of members that would otherwise follow it (in this case `u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This overlays the trailing members (rss_hash_key_data) onto the FAM (hash_key_data) while keeping the FAM and the start of MEMBERS aligned. The static_assert() ensures this alignment remains. Notice that due to tail padding in flexible `struct virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data` (at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at offset 84 in struct virtnet_info) are misaligned by one byte. See below: struct virtio_net_rss_config_trailer { __le16 max_tx_vq; /* 0 2 */ __u8 hash_key_length; /* 2 1 */ __u8 hash_key_data[]; /* 3 0 */ /* size: 4, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 4 bytes */ }; struct virtnet_info { ... struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */ /* XXX last struct has 1 byte of padding */ u8 rss_hash_key_data[40]; /* 84 40 */ ... /* size: 832, cachelines: 13, members: 48 */ /* sum members: 801, holes: 8, sum holes: 31 */ /* paddings: 2, sum paddings: 5 */ }; After changes, those members are correctly aligned at offset 795: struct virtnet_info { ... union { struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */ struct { unsigned char __offset_to_hash_key_data[3]; /* 792 3 */ u8 rss_hash_key_data[40]; /* 795 40 */ }; /* 792 43 */ }; /* 792 44 */ ... /* size: 840, cachelines: 14, members: 47 */ /* sum members: 801, holes: 8, sum holes: 35 */ /* padding: 4 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 8 bytes */ }; As a result, the RSS key passed to the device is shifted by 1 byte: the last byte is cut off, and instead a (possibly uninitialized) byte is added at the beginning. As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also moved to the end, since it seems those three members should stick around together. :) Cc: stable@vger.kernel.org Fixes: ed3100e90d0d ("virtio_net: Use new RSS config structs") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/aWIItWq5dV9XTTCJ@kspp Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15Merge branch 'xsk-move-cq_cached_prod_lock'Paolo Abeni
Jason Xing says: ==================== xsk: move cq_cached_prod_lock From: Jason Xing <kernelxing@tencent.com> Move cq_cached_prod_lock to avoid touching new cacheline. Acked-by: Stanislav Fomichev <sdf@fomichev.me> ==================== Link: https://patch.msgid.link/20260104012125.44003-1-kerneljasonxing@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending pathJason Xing
We (Paolo and I) noticed that in the sending path touching an extra cacheline due to cq_cached_prod_lock will impact the performance. After moving the lock from struct xsk_buff_pool to struct xsk_queue, the performance is increased by ~5% which can be observed by xdpsock. An alternative approach [1] can be using atomic_try_cmpxchg() to have the same effect. But unfortunately I don't have evident performance numbers to prove the atomic approach is better than the current patch. The advantage is to save the contention time among multiple xsks sharing the same pool while the disadvantage is losing good maintenance. The full discussion can be found at the following link. [1]: https://lore.kernel.org/all/20251128134601.54678-1-kerneljasonxing@gmail.com/ Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Jason Xing <kernelxing@tencent.com> Link: https://patch.msgid.link/20260104012125.44003-3-kerneljasonxing@gmail.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15xsk: advance cq/fq check when shared umem is usedJason Xing
In the shared umem mode with different queues or devices, either uninitialized cq or fq is not allowed which was previously done in xp_assign_dev_shared(). The patch advances the check at the beginning so that 1) we can avoid a few memory allocation and stuff if cq or fq is NULL, 2) it can be regarded as preparation for the next patch in the series. Signed-off-by: Jason Xing <kernelxing@tencent.com> Link: https://patch.msgid.link/20260104012125.44003-2-kerneljasonxing@gmail.com Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-15net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon ↵Tetsuo Handa
receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem. Reported-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://patch.msgid.link/b1212653-8fa1-44e1-be9d-12f950fb3a07@I-love.SAKURA.ne.jp Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-01-15Merge patch series "can: raw: better approach to instantly reject ↵Marc Kleine-Budde
unsupported CAN frames" Oliver Hartkopp <socketcan@hartkopp.net> says: This series reverts commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames"). and its follow-up fixes for the introduced dependency issues. commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") commit cb2dc6d2869a ("can: Kconfig: select CAN driver infrastructure by default") commit 6abd4577bccc ("can: fix build dependency") commit 5a5aff6338c0 ("can: fix build dependency") The reverted patch was accessing CAN device internal data structures from the network layer because it needs to know about the CAN protocol capabilities of the CAN devices. This data access caused build problems between the CAN network and the CAN driver layer which introduced unwanted Kconfig dependencies and fixes. The patches 2 & 3 implement a better approach which makes use of the CAN specific ml_priv data which is accessible from both sides. With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored. Link: https://patch.msgid.link/20260109144135.8495-1-socketcan@hartkopp.net [mkl: give series a more descriptive name] [mkl: properly format reverted patch commitish] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-01-15can: raw: instantly reject disabled CAN framesOliver Hartkopp
For real CAN interfaces the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL control modes indicate whether an interface can handle those CAN FD/XL frames. In the case a CAN XL interface is configured in CANXL-only mode with disabled error-signalling neither CAN CC nor CAN FD frames can be sent. The checks are now performed on CAN_RAW sockets to give an instant feedback to the user when writing unsupported CAN frames to the interface or when the CAN interface is in read-only mode. Fixes: 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Vincent Mailhol <mailhol@kernel.org> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260109144135.8495-4-socketcan@hartkopp.net [mkl: fix dev reference leak] Link: https://lore.kernel.org/all/0636c732-2e71-4633-8005-dfa85e1da445@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-01-15can: propagate CAN device capabilities via ml_privOliver Hartkopp
Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides. With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored. Fixes: 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Vincent Mailhol <mailhol@kernel.org> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260109144135.8495-3-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>