summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-05-08net: dsa: microchip: ensure each ksz_dev_ops has its own dsa_switch_opsVladimir Oltean
Currently we have a single dsa_switch_ops for 4 very distinct families of switches, and many dsa_switch_ops methods are simply a dispatches through ksz_dev_ops. That creates an avoidable level of indirection. As a preparation for removing that indirection layer, create a separate dsa_switch_ops structure wherever we have a ksz_dev_ops. These structures are not yet used - ksz_switch_ops from ksz_common.c still is. However, this reduces the noise from subsequent changes. All new dsa_switch_ops are exact copies of ksz_switch_ops. But we need to export function prototypes from ksz_common.c so that they are callable from individual drivers. Note that "individual drivers" are not actual separate kernel modules. All of ksz8.c, ksz9477.c and lan937x_main.c are part of the same ksz_switch.ko. Only the "register interface" drivers are different modules (ksz9477_i2c.o for I2C, ksz_spi.o for SPI, ksz8863_smi.o for MDIO). So we don't need to export any symbol. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-6-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: dsa: microchip: move phylink_mac_ops to individual driversVladimir Oltean
Similar to ksz_dev_ops, struct phylink_mac_ops shouldn't be part of the common code. Instead, the common code should provide callable functionality. Invert the paradigm and export the common aspects from ksz_common.c, and move the chip-specific stuff in individual drivers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-5-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: dsa: microchip: move KSZ9477 and LAN937 ksz_dev_ops to individual driversVladimir Oltean
The ksz_dev_ops() are specific to each switch family so they should belong to the individual drivers instead of the common section. Move the ksz_dev_ops() definitions of the KSZ9477 and the LAN937 to their individual drivers. Set static the functions that aren't exported anymore. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-4-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: dsa: microchip: move KSZ8 ksz_dev_ops to ksz8.cVladimir Oltean
The ksz_dev_ops() are specific to each switch family so they should belong to the individual drivers instead of the common section. Move the ksz_dev_ops() definitions of the KSZ8xxx to ksz8.c Set static the functions that aren't exported anymore. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-3-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: dsa: microchip: remove unused port_cleanup() callbackBastien Curutchet (Schneider Electric)
ksz_dev_ops :: port_cleanup() isn't used anywhere. Remove it. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-2-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: dsa: microchip: Remove unused ksz8_all_queues_split()Bastien Curutchet (Schneider Electric)
ksz8_all_queues_split() isn't used anywhere. Remove it. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260505-clean-ksz-driver-v1-1-05d70fa42461@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net/mlx5: Add VHCA_ID page management mode supportMoshe Shemesh
Add support for VHCA_ID-based page management mode. When the device firmware advertises the icm_mng_function_id_mode capability with MLX5_ID_MODE_FUNCTION_VHCA_ID, page management operations between the driver and firmware may use vhca_id instead of function_id as the effective function identifier, and the ec_function field is ignored. Update page management commands to conditionally set ec_function field only in FUNC_ID mode. Boot page allocation always uses FUNC_ID mode semantics for backward compatibility, as the capability bit is only available after set_hca_cap(). If after set_hca_cap() VHCA_ID mode was set, modify the tracking of the boot pages in page_root_xa to use vhca_id too. Add mlx5_esw_vhca_id_to_func_type() to resolve the function type in VHCA_ID mode, enabling per-type debugfs counters. Use a dedicated vhca_type_map xarray, to provide lockless lookup. Store the resolved type on each fw_page at allocation time so reclaim and release paths read it directly without any lookup. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260506133239.276237-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net/mlx5: Make debugfs page counters by function type dynamicMoshe Shemesh
Make the per function type debugfs page counters dynamically added after mlx5_eswitch_init(). When page management operates in vhca_id mode, only the function acting as either eSwitch or vport manager can initialize the eSwitch structure and translate the vhca_id to function type for the functions to which it supplies pages. The next patch will add support for page management in vhca_id mode. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260506133239.276237-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net/mlx5: Relax capability check for eswitch query pathsMoshe Shemesh
Several eswitch functions that only query other functions' HCA capabilities or read cached vport state are guarded by the vhca_resource_manager capability. This capability is required for set_hca_cap operations but query_hca_cap of other functions only requires the vport_group_manager capability. Relax the capability check from vhca_resource_manager to vport_group_manager in the following query-only paths: - mlx5_esw_vport_caps_get() - queries other function general caps - esw_ipsec_vf_query_generic() - queries other function ipsec cap - mlx5_devlink_port_fn_migratable_get() - reads cached vport state - mlx5_devlink_port_fn_roce_get() - reads cached vport state - mlx5_devlink_port_fn_max_io_eqs_get() - queries other function caps - mlx5_esw_vport_enable/disable() - vhca_id map/unmap Functions that perform also set_hca_cap (migratable_set, roce_set, max_io_eqs_set, esw_ipsec_vf_set_generic, esw_ipsec_vf_set_bytype) retain the vhca_resource_manager requirement. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260506133239.276237-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memcleanHolger Brunck
When the device is removed all allocated resources should be freed. In uhdlc_memclean the netdev transmit queue was already stopped. But at this point we may have pending skb in the transmit queue which must be freed. Therefore iterate over the tx_skbuff pointers and free all pending skb. The issue was discovered by sashiko. Tested on a ls1043a board running HDLC in bus mode on kernel 6.12. https: //sashiko.dev/#/patchset/20260429114208.941011-1-holger.brunck%40hitachienergy.com Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC") Signed-off-by: Holger Brunck <holger.brunck@hitachienergy.com> Link: https://patch.msgid.link/20260507155332.3452319-1-holger.brunck@hitachienergy.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08ixgbe: E610: do not fill EEE lp_advertised from local PHY capsDavid Carlier
ixgbe_get_eee_e610() fills kedata->lp_advertised from pcaps.eee_cap returned by ixgbe_aci_get_phy_caps() with IXGBE_ACI_REPORT_ACTIVE_CFG. That report mode (and the other IXGBE_ACI_REPORT_* modes) describe the local PHY only, not the link partner. The X550 path uses a separate FW_PHY_ACT_UD_2 activity for partner data; the E610 ACI has no equivalent. Leave lp_advertised zeroed via the existing linkmode_zero() and drop the now-unused ixgbe_eee_cap_map[]. eee_active/eee_enabled are unaffected (sourced from link.eee_status). Fixes: b61dbdeff3a9 ("ixgbe: E610: add EEE support") Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260507-jk-iwl-next-fix-eee-ixgbe-v1-1-62bc1d197d1d@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: ti: icssm-prueth: fix eth_ports_node leak in probeShitalkumar Gandhi
The error path on of_property_read_u32() failure inside icssm_prueth_probe() returns without putting eth_ports_node, which was acquired before the for_each_child_of_node() loop. Drop it before returning. Fixes: 511f6c1ae093 ("net: ti: icssm-prueth: Adds ICSSM Ethernet driver") Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com> Link: https://patch.msgid.link/20260506195813.641610-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: bcmasp: Keep phy link during WoL sleep cycleJustin Chen
We currently more or less restart all the HW on resume. Since we also stop the PHY, it takes a while for the PHY link to be re-negotiated on resume. Instead of doing a full restart, we keep the HW state and the PHY link, that way we can resume network traffic with a much smaller delay. Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260506213114.2002886-3-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: bcmasp: Divide init to allow partial bring upJustin Chen
To prepare for a partial bring up of the interface during resume, we break apart the bcmasp_netif_init() function into smaller chunks that can be called as necessary. Also consolidate some functions that do not need to be standalone. Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260506213114.2002886-2-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: lan966x: avoid unregistering netdev on register failureMyeonghun Pak
lan966x_probe_port() stores the newly allocated net_device in the port before calling register_netdev(). If register_netdev() fails, the probe error path calls lan966x_cleanup_ports(), which sees port->dev and calls unregister_netdev() for a device that was never registered. Destroy the phylink instance created for this port and clear port->dev before returning the registration error. The common cleanup path now skips ports without port->dev before reaching the registered netdev cleanup, so it only handles ports that reached the registered-netdev lifetime. This also avoids treating an uninitialized FDMA netdev and the failed port as a NULL == NULL match in the common cleanup path. Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Link: https://patch.msgid.link/20260506124331.31945-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08ice: dpll: fix misplaced header macrosIvan Vecera
The CGU register definitions (ICE_CGU_R10, ICE_CGU_R11 and related field masks) were placed after the #endif of the _ICE_DPLL_H_ include guard, leaving them unprotected. Move them inside the guard. Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-8-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08ice: dpll: fix rclk pin state get for E810Ivan Vecera
The refactoring of ice_dpll_rclk_state_on_pin_get() to use ice_dpll_pin_get_parent_idx() omitted the base_rclk_idx adjustment that was correctly added in the ice_dpll_rclk_state_on_pin_set() path. This breaks E810 devices where base_rclk_idx is non-zero, causing the wrong hardware index to be used for pin state lookup and incorrect recovered clock state to be reported via the DPLL subsystem. E825C is unaffected as its base_rclk_idx is 0. While at it, add bounds check against ICE_DPLL_RCLK_NUM_MAX on hw_idx after the base_rclk_idx subtraction in both ice_dpll_rclk_state_on_pin_{get,set}() to prevent out-of-bounds access on the pin state array. Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-7-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08ice: fix locking in ice_dcb_rebuild()Bart Van Assche
Move the mutex_lock() call up to prevent that DCB settings change after the first ice_query_port_ets() call. The second ice_query_port_ets() call in ice_dcb_rebuild() is already protected by pf->tc_mutex. This also fixes a bug in an error path, as before taking the first "goto dcb_error" in the function jumped over mutex_lock() to mutex_unlock(). This bug has been detected by the clang thread-safety analyzer. Cc: intel-wired-lan@lists.osuosl.org Fixes: 242b5e068b25 ("ice: Fix DCB rebuild after reset") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-6-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08ice: fix setting RSS VSI hash for E830Marcin Szycik
ice_set_rss_hfunc() performs a VSI update, in which it sets hashing function, leaving other VSI options unchanged. However, ::q_opt_flags is mistakenly set to the value of another field, instead of its original value, probably due to a typo. What happens next is hardware-dependent: On E810, only the first bit is meaningful (see ICE_AQ_VSI_Q_OPT_PE_FLTR_EN) and can potentially end up in a different state than before VSI update. On E830, some of the remaining bits are not reserved. Setting them to some unrelated values can cause the firmware to reject the update because of invalid settings, or worse - succeed. Reproducer: sudo ethtool -X $PF1 equal 8 Output in dmesg: Failed to configure RSS hash for VSI 6, error -5 Fixes: 352e9bf23813 ("ice: enable symmetric-xor RSS for Toeplitz hash function") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-5-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08idpf: fix double free and use-after-free in aux device error pathsGreg Kroah-Hartman
When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or idpf_plug_core_aux_dev(), the err_aux_dev_add label calls auxiliary_device_uninit() and falls through to err_aux_dev_init. The uninit call will trigger put_device(), which invokes the release callback (idpf_vport_adev_release / idpf_core_adev_release) that frees iadev. The fall-through then reads adev->id from the freed iadev for ida_free() and double-frees iadev with kfree(). Free the IDA slot and clear the back-pointer before uninit, while adev is still valid, then return immediately. Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization") fixed the same use-after-free in the matching unplug path in this file but missed both probe error paths. Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: stable@kernel.org Fixes: be91128c579c ("idpf: implement RDMA vport auxiliary dev create, init, and destroy") Fixes: f4312e6bfa2a ("idpf: implement core RDMA auxiliary dev create, init, and destroy") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-4-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()Emil Tantilov
In idpf_ptp_init(), read_dev_clk_lock is initialized after ptp_schedule_worker() had already been called (and after idpf_ptp_settime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpf_ptp_read_src_clk_reg_direct(), which takes spin_lock(&ptp->read_dev_clk_lock) on an uninitialized lock, triggering the lockdep "non-static key" warning: [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dump_stack_lvl+0x93/0xe0 [12974.097234] register_lock_class+0x4c4/0x4e0 [12974.097249] ? __lock_acquire+0x427/0x2290 [12974.097259] __lock_acquire+0x98/0x2290 [12974.097272] lock_acquire+0xc6/0x310 [12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190 [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350 [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp] [12974.097343] _raw_spin_lock+0x30/0x40 [12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097391] ? kthread_worker_fn+0x88/0x3d0 [12974.097404] ? kthread_worker_fn+0x4e/0x3d0 [12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf] [12974.097428] ? _raw_spin_unlock_irq+0x28/0x50 [12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf] [12974.097454] ptp_aux_kworker+0x20/0x40 [ptp] [12974.097464] kthread_worker_fn+0xd5/0x3d0 [12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? __pfx_kthread+0x10/0x10 [12974.097498] ret_from_fork+0x32c/0x410 [12974.097512] ? __pfx_kthread+0x10/0x10 [12974.097519] ret_from_fork_asm+0x1a/0x30 [12974.097540] </TASK> Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock is not touched before it's been initialized. Fixes: 5cb8805d2366 ("idpf: negotiate PTP capabilities and get PTP clock") Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-3-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08i40e: Cleanup PTP pins on probe failureMatt Vollrath
PTP pin structs are allocated early in probe, but never cleaned up. Fix this by calling i40e_ptp_free_pins in the error path. To support this, i40e_ptp_free_pins is added to the header and pin_config is correctly nullified after being freed. This has been an issue since i40e_ptp_alloc_pins was introduced. Fixes: 1050713026a08 ("i40e: add support for PTP external synchronization clock") Reported-by: Kohei Enju <kohei@enjuk.jp> Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath <tactii@gmail.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Kohei Enju <kohei@enjuk.jp> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-2-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08i40e: Cleanup PTP registration on probe failureMatt Vollrath
Fix two conditions which would leak PTP registration on probe failure: 1. i40e_setup_pf_switch can encounter an error in i40e_setup_pf_filter_control, call i40e_ptp_init, then return non-zero, sending i40e_probe to err_vsis. 2. i40e_setup_misc_vector can return non-zero, sending i40e_probe to err_vsis. Both of these conditions have been present since PTP was introduced in this driver. Found with coccinelle. Fixes: beb0dff1251db ("i40e: enable PTP") Signed-off-by: Matt Vollrath <tactii@gmail.com> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260506-jk-iwl-net-2026-05-04-v2-1-a5ea4dc837a9@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: phy: dp83867: add MDI-X managementLuca Ellero
ethtool on this phy device always reports "MDI-X: Unknown" and doesn't support forcing it to on or off. This patch adds support for reading/forcing MDI-X mode from ethtool properly. Signed-off-by: Luca Ellero <l.ellero@asem.it> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260506141918.13136-1-l.ellero@asem.it Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08gve: Use generic power managementVaibhav Gupta
Switch to the generic power management and remove the usage of legacy (pci_driver) hooks. Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260506165015.641738-1-vaibhavgupta40@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08bnxt_en: Drop pci_save_state() after pci_restore_state()Lukas Wunner
Commit 383d89699c50 ("treewide: Drop pci_save_state() after pci_restore_state()") sought to purge all superfluous invocations of pci_save_state() from the tree. Unfortunately the commit missed one invocation in the Broadcom NetXtreme-C/E driver. Drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/39de1b025928d9a457976010b2324e7e99baa92a.1778158755.git.lukas@wunner.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-08net: ethernet: atheros: atl2: remove kernel backward-compatibility codeEthan Nelson-Moore
The atl2 driver contains code for compatibility with old kernels that do not support module_param_array. Backward compatibility is irrelevant because this driver is in-tree. Remove this unreachable code to simplify the driver's handling of module parameters. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260506054035.23710-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.1-rc3). Conflicts: net/ipv4/igmp.c 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation") c6bebaa744f7 ("ipv4: igmp: annotate data-races in igmp_heard_query()") https://lore.kernel.org/a7365e4873340f7a5e30411207de3bf9@kernel.org Adjacent changes: net/psp/psp_main.c 30cb24f97d44 ("psp: strip variable-length PSP header in psp_dev_rcv()") c2b22277ad89 ("psp: validate IPv4 header fields in psp_dev_rcv()") net/sched/sch_fq_codel.c f83e07b29246 ("net/sched: sch_fq_codel: annotate data-races from fq_codel_dump_class_stats()") 3f3aa77ff1c8 ("net/sched: add qstats_cpu_drop_inc() helper") net/wireless/pmsr.c 0f3c0a197309 ("wifi: nl80211: fix NL80211_PMSR_FTM_REQ_ATTR_FTMS_PER_BURST usage") 410aa47fd9d3 ("wifi: cfg80211: allow suppressing FTM result reporting for PD requests") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07Merge tag 'net-7.1-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Netfilter, IPsec, Bluetooth and WiFi. Current release - fix to a fix: - ipmr: add __rcu to netns_ipv4.mrt, make sure we hold the RCU lock in all relevant places Current release - new code bugs: - fixes for the recently added resizable hash tables - ipv6: make sure we default IPv6 tunnel drivers to =m now that IPv6 itself is built in - drv: octeontx2-af: fixes for parser/CAM fixes Previous releases - regressions: - phy: micrel: fix LAN8814 QSGMII soft reset - wifi: - cw1200: revert "Fix locking in error paths" - ath12k: fix crash on WCN7850, due to adding the same queue buffer to a list multiple times Previous releases - always broken: - number of info leak fixes - ipv6: implement limits on extension header parsing - wifi: number of fixes for missing bound checks in the drivers - Bluetooth: fixes for races and locking issues - af_unix: - fix an issue between garbage collection and PEEK - fix yet another issue with OOB data - xfrm: esp: avoid in-place decrypt on shared skb frags - netfilter: replace skb_try_make_writable() by skb_ensure_writable() - openvswitch: vport: fix race between tunnel creation and linking leading to invalid memory accesses (type confusion) - drv: amd-xgbe: fix PTP addend overflow causing frozen clock Misc: - sched/isolation: make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN (for relevant IPVS change)" * tag 'net-7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (190 commits) net: sparx5: configure serdes for 1000BASE-X in sparx5_port_init() net: sparx5: fix wrong chip ids for TSN SKUs net: stmmac: dwmac-nuvoton: fix NULL pointer dereference in nvt_set_phy_intf_sel() tcp: Fix dst leak in tcp_v6_connect(). ipmr: Call ipmr_fib_lookup() under RCU. net: phy: broadcom: Save PHY counters during suspend net/smc: fix missing sk_err when TCP handshake fails af_unix: Reject SIOCATMARK on non-stream sockets veth: fix OOB txq access in veth_poll() with asymmetric queue counts eth: fbnic: fix double-free of PCS on phylink creation failure net: ethernet: cortina: Drop half-assembled SKB selftests: mptcp: pm: restrict 'unknown' check to pm_nl_ctl selftests: mptcp: check output: catch cmd errors mptcp: pm: prio: skip closed subflows mptcp: pm: ADD_ADDR rtx: return early if no retrans mptcp: pm: ADD_ADDR rtx: skip inactive subflows mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker mptcp: pm: ADD_ADDR rtx: free sk if last mptcp: pm: ADD_ADDR rtx: always decrease sk refcount mptcp: pm: ADD_ADDR rtx: fix potential data-race ...
2026-05-07net: sparx5: configure serdes for 1000BASE-X in sparx5_port_init()Daniel Machon
sparx5_port_init() only invokes sparx5_serdes_set() and the associated shadow-device enable and low-speed device switch for SGMII and QSGMII. On any port with a high-speed primary device (DEV5G/DEV10G/DEV25G) configured for 1000BASE-X the serdes is therefore left uninitialized, the DEV2G5 shadow is never enabled, and the port stays pointed at its high-speed device rather than the DEV2G5. The PCS1G block looks healthy in isolation, but no frames reach the link partner. Add 1000BASE-X to the check so the same three steps run. Note: the same issue might apply to 2500BASE-X, but that will, eventually, be addressed in a separate commit. Reported-by: Andrew Lunn <andrew@lunn.ch> Fixes: 946e7fd5053a ("net: sparx5: add port module support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20260506-misc-fixes-sparx5-lan969x-v2-4-fb236aa96908@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07net: sparx5: fix wrong chip ids for TSN SKUsDaniel Machon
The TSN SKUs in enum spx5_target_chiptype have incorrect IDs: SPX5_TARGET_CT_7546TSN = 0x47546, SPX5_TARGET_CT_7549TSN = 0x47549, SPX5_TARGET_CT_7552TSN = 0x47552, SPX5_TARGET_CT_7556TSN = 0x47556, SPX5_TARGET_CT_7558TSN = 0x47558, The value read back from the chip is GCB_CHIP_ID_PART_ID, which is a GENMASK(27, 12) field, i.e. at most 16 bits wide. It can never match these IDs, so probing a TSN part fails with a "Target not supported" error. Fix the enum to use the actual 16-bit part IDs returned by the hardware: 0x0546, 0x0549, 0x0552, 0x0556 and 0x0558. Reported-by: Andrew Lunn <andrew@lunn.ch> Fixes: 3cfa11bac9bb ("net: sparx5: add the basic sparx5 driver") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20260506-misc-fixes-sparx5-lan969x-v2-3-fb236aa96908@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07net: stmmac: dwmac-nuvoton: fix NULL pointer dereference in ↵Joey Lu
nvt_set_phy_intf_sel() priv->dev was never initialized after devm_kzalloc() allocates the private data structure. When nvt_set_phy_intf_sel() is later invoked via the phylink interface_select callback, it calls nvt_gmac_get_delay(priv->dev, ...) which dereferences the NULL pointer. Fix this by assigning priv->dev = dev immediately after allocation. Fixes: 4d7c557f58ef ("net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family") Signed-off-by: Joey Lu <a0987203069@gmail.com> Link: https://patch.msgid.link/20260506084614.192894-2-a0987203069@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07net: phy: broadcom: Save PHY counters during suspendJustin Chen
The PHY counters can be lost if the PHY is reset during suspend. We need to save the values into the shadow counters or the accounting will be incorrect over multiple suspend and resume cycles. Fixes: 820ee17b8d3b ("net: phy: broadcom: Add support code for reading PHY counters") Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20260505173926.2870069-1-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07veth: fix OOB txq access in veth_poll() with asymmetric queue countsJesper Dangaard Brouer
XDP redirect into a veth device (via bpf_redirect()) calls veth_xdp_xmit(), which enqueues frames into the peer's ptr_ring using smp_processor_id() % peer->real_num_rx_queues as the ring index. With an asymmetric veth pair where the peer has fewer TX queues than RX queues, that index can exceed peer->real_num_tx_queues. veth_poll() then resolves peer_txq for the ring via: peer_txq = peer_dev ? netdev_get_tx_queue(peer_dev, queue_idx) : NULL; where queue_idx = rq->xdp_rxq.queue_index. When queue_idx exceeds peer_dev->real_num_tx_queues this is an out-of-bounds (OOB) access into the peer's netdev_queue array, triggering DEBUG_NET_WARN_ON_ONCE in netdev_get_tx_queue(). The normal ndo_start_xmit path is not affected: the stack clamps skb->queue_mapping via netdev_cap_txqueue() before invoking ndo_start_xmit, so rxq in veth_xmit() never exceeds real_num_tx_queues. Fix veth_poll() by clamping: only dereference peer_txq when queue_idx is within bounds, otherwise set it to NULL. The out-of-range rings are fed exclusively via XDP redirect (veth_xdp_xmit), never via ndo_start_xmit (veth_xmit), so the peer txq was never stopped and there is nothing to wake; NULL is the correct fallback. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260502071828.616C3C19425@smtp.kernel.org/ Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/20260505132159.241305-2-hawk@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-07eth: fbnic: fix double-free of PCS on phylink creation failureBobby Eshleman
fbnic_phylink_create() stores the newly allocated PCS in fbn->pcs and then calls phylink_create(). When phylink_create() fails, the error path correctly destroys the PCS via xpcs_destroy_pcs(), but the caller, fbnic_netdev_alloc(), responds by invoking fbnic_netdev_free() which calls fbnic_phylink_destroy(). That function finds fbn->pcs non-NULL and calls xpcs_destroy_pcs() a second time on the already-freed object, triggering a refcount underflow use-after-free: [ 1.934973] fbnic 0000:01:00.0: Failed to create Phylink interface, err: -22 [ 1.935103] ------------[ cut here ]------------ [ 1.935179] refcount_t: underflow; use-after-free. [ 1.935252] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x59/0x90, CPU#0: swapper/0/1 [ 1.935389] Modules linked in: [ 1.935484] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-virtme-04244-g1f5ffc672165-dirty #1 PREEMPT(lazy) [ 1.935661] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 1.935826] RIP: 0010:refcount_warn_saturate+0x59/0x90 [ 1.935931] Code: 44 48 8d 3d 49 f9 a7 01 67 48 0f b9 3a e9 bf 1e 96 00 48 8d 3d 48 f9 a7 01 67 48 0f b9 3a c3 cc cc cc cc 48 8d 3d 47 f9 a7 01 <67> 48 0f b9 3a c3 cc cc cc cc 48 8d 3d 46 f9 a7 01 67 48 0f b9 3a [ 1.936274] RSP: 0000:ffffd0d440013c58 EFLAGS: 00010246 [ 1.936376] RAX: 0000000000000000 RBX: ffff8f39c188c278 RCX: 000000000000002b [ 1.936524] RDX: ffff8f39c004f000 RSI: 0000000000000003 RDI: ffffffff96abab00 [ 1.936692] RBP: ffff8f39c188c240 R08: ffffffff96988e88 R09: 00000000ffffdfff [ 1.936835] R10: ffffffff96878ea0 R11: 0000000000000187 R12: 0000000000000000 [ 1.936970] R13: ffff8f39c0cef0c8 R14: ffff8f39c1ac01c0 R15: 0000000000000000 [ 1.937114] FS: 0000000000000000(0000) GS:ffff8f3ba08b4000(0000) knlGS:0000000000000000 [ 1.937273] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.937382] CR2: ffff8f3b3ffff000 CR3: 0000000172642001 CR4: 0000000000372ef0 [ 1.937540] Call Trace: [ 1.937619] <TASK> [ 1.937698] xpcs_destroy_pcs+0x25/0x40 [ 1.937783] fbnic_netdev_alloc+0x1e5/0x200 [ 1.937859] fbnic_probe+0x230/0x370 [ 1.937939] local_pci_probe+0x3e/0x90 [ 1.938013] pci_device_probe+0xbb/0x1e0 [ 1.938091] ? sysfs_do_create_link_sd+0x6d/0xe0 [ 1.938188] really_probe+0xc1/0x2b0 [ 1.938282] __driver_probe_device+0x73/0x120 [ 1.938371] driver_probe_device+0x1e/0xe0 [ 1.938466] __driver_attach+0x8d/0x190 [ 1.938560] ? __pfx___driver_attach+0x10/0x10 [ 1.938663] bus_for_each_dev+0x7b/0xd0 [ 1.938758] bus_add_driver+0xe8/0x210 [ 1.938854] driver_register+0x60/0x120 [ 1.938929] ? __pfx_fbnic_init_module+0x10/0x10 [ 1.939026] fbnic_init_module+0x25/0x60 [ 1.939109] do_one_initcall+0x49/0x220 [ 1.939202] ? rdinit_setup+0x20/0x40 [ 1.939304] kernel_init_freeable+0x1b0/0x310 [ 1.939449] ? __pfx_kernel_init+0x10/0x10 [ 1.939560] kernel_init+0x1a/0x1c0 [ 1.939640] ret_from_fork+0x1ed/0x240 [ 1.939730] ? __pfx_kernel_init+0x10/0x10 [ 1.939805] ret_from_fork_asm+0x1a/0x30 [ 1.939886] </TASK> [ 1.939927] ---[ end trace 0000000000000000 ]--- [ 1.940184] fbnic 0000:01:00.0: Netdev allocation failed Instead of calling fbnic_phylink_destroy(), the prior initialization of netdev should just be unrolled with free_netdev() and clearing fbd->netdev. Clearing fbd->netdev to NULL avoids UAF in init_failure_mode where callers guard by checking !fbd->netdev, such as fbnic_mdio_read_pmd(). These callers remain active even after a failed probe, so fdb->netdev still needs to be cleared. Fixes: d0fe7104c795 ("fbnic: Replace use of internal PCS w/ Designware XPCS") Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260504-fbnic-pcs-fix-v2-1-de45192821d9@meta.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-06w5100: remove unused gpio link detectionArnd Bergmann
Since the platform_device support is now gone, nothing ever passes a valid gpio number, and all the link state handling can go away. An earlier version of my patch changed this to look up the GPIO descriptor from devicetree and convert it all to the modern interface, but there are no users of that binding at the moment. Remove the gpio handling, which is now one of the last users of the legacy gpio interface in platform-independent code. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/20230127095839.3266452-1-arnd@kernel.org/ Link: https://patch.msgid.link/20260505180459.1247690-3-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06w5300: remove unused driverArnd Bergmann
Unlike w5100, this driver does not support SPI mode or devicetree bindings, and is hence entirely unusable without third-party board support patches that likely haven't existed for any recent kernel version. Remove the entire driver. If anyone is in fact using it with their custom board files, they can bring it back and include an earlier patch I sent to add DT based probing for the GPIO lines. Link: https://lore.kernel.org/all/20260427142924.2702598-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260505180459.1247690-2-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06w5100: remove MMIO supportArnd Bergmann
This driver supports both SPI and MMIO based register access, but only the former has devicetree support. While MMIO mode would have worked with old-style board files, those have never defined such a device upstream. Remove the MMIO mode, leaving SPI as the only way to use this driver, but leave it in two loadable modules. More cleanups can be done by combining the two into one file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260505180459.1247690-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, load reps via work queue after registrationMark Bloch
mlx5_eswitch_register_vport_reps() only installs representor callbacks and marks the rep type as registered. If the E-Switch is already in switchdev mode, the newly registered rep type must then be loaded for already enabled vports. That load path needs to run under the devlink lock, which is not held by the auxiliary driver registration context. Queue the reload to the E-Switch workqueue, whose handler acquires the devlink lock, and load the relevant representors from there. Since representor registration runs from sleepable auxiliary-driver context, queue the late reload with GFP_KERNEL. The functions-change notifier path remains the GFP_ATOMIC user of mlx5_esw_add_work(). The unregister path is unchanged and still unloads representors synchronously while tearing down the registered callbacks. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, unwind only newly loaded representor typesMark Bloch
__esw_offloads_load_rep() may return success without invoking the representor load callback when the representor type is already loaded. On a later load failure, mlx5_esw_offloads_rep_load() unconditionally unloaded all previously iterated representor types. This could unload representor types that were already loaded before this load attempt. Track which representor types were actually loaded by the current call and unwind only those on error. Also restore the representor state back to REP_REGISTERED when the load callback itself fails. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, serialize representor lifecycleMark Bloch
Representor callbacks can be registered and unregistered while the E-Switch is already in switchdev mode, and the same E-Switch may also be reconfigured by devlink, VF changes and SF changes. Serialize these paths with the per-E-Switch representor mutex instead of relying on ad-hoc bit state and wait queues. Take the representor lock around the mode transition, VF/SF representor changes and representor ops registration. Keep mode_lock and the representor lock unnested by using the operation flag while the mode lock is dropped. During mode changes, drop the representor lock around the auxiliary bus rescan because driver bind/unbind may register or unregister representor ops. Split representor ops registration into locked public wrappers and blocked internal helpers, clear the ops pointer on unregister, and add nested wrappers for the shared-FDB master IB path that registers peer representor ops while another E-Switch representor lock is already held. On unregister, always call __unload_reps_all_vport() before marking reps unregistered and clearing rep_ops. The per-representor state check makes this a no-op for types that were not loaded, so unregister no longer has to infer load state from esw->mode. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: Lag, avoid LAG and representor lock cyclesMark Bloch
The LAG shared-FDB and multiport E-Switch transitions rescan auxiliary devices and reload IB representors while holding ldev->lock. Driver bind/unbind paths may register or unregister E-Switch representor ops, and representor load paths may enter LAG code, so holding ldev->lock across those calls creates lock-order cycles with the E-Switch representor lock. Keep the devcom component locked for the transition, but drop ldev->lock before rescanning auxiliary devices or reloading IB representors. Mark the LAG transition as in progress while the lock is dropped and assert the devcom lock where the helper relies on it. This preserves LAG serialization while avoiding ldev->lock nesting under E-Switch representor registration. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, add representor lifecycle lockMark Bloch
Add a per-E-Switch mutex for serializing representor lifecycle work and provide small helpers for taking and dropping it. Initialize and destroy the mutex with the E-Switch offloads state. Add the lock and helper API first. Follow-up patches will take the lock in the individual representor lifecycle components. This keeps the functional changes split by component and leaves this patch without intended behavior change, making the series easier to review and bisectable. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, let esw work callers choose GFP flagsMark Bloch
mlx5_esw_add_work() always allocates the queued work item with GFP_ATOMIC. That is required for the E-Switch functions-change notifier, but not every caller of this helper will run from atomic context. Pass an allocation flag to mlx5_esw_add_work() and keep the notifier caller using GFP_ATOMIC. This allows sleepable callers to use GFP_KERNEL instead of unnecessarily relying on atomic reserves. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: Lag: refactor representor reload handlingMark Bloch
Representor reload during LAG/MPESW transitions has to be repeated in several flows, and each open-coded loop was easy to get out of sync when adding new flags or tweaking error handling. Move the sequencing into a single helper so that all call sites share the same ordering and checks. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add firmware upload capability for RTL8157/RTL8159Birger Koblitz
The RTL8159 (RTL_VER_17) requires firmware for its PHY in order to work at connection speeds > 5GBit. Add support for uploading firmware for the PHY using the existing rtl8152_apply_firmware() function in r8157_hw_phy_cfg() and set up the correct names for the firmware files. This also adds support for uploading firmware for the RTL8157 (RTL_VER_16) PHY, for which firmware is however not strictly necessary to work. Still, this allows to upload newer versions of the firmware used by this chip, e.g. to improve interoperability. If no firmware is found, both the RTL8157 and the RTL8159 will continue to work. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-3-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add support for the RTL8159 chipBirger Koblitz
The RTL8159 re-uses the packet descriptor format introduced with the RTL8157 and other hardware features of the RTL8157 (RTL_VER_16) such as the SRAM access. The support therefore consists in expanding the existing RTL8157 code for initialization and USB power management to also be used for the RTL8159 (RTL_VER_17). Most of the additional code is added in r8157_hw_phy_cfg() to configure the RTL8159 PHY. Add support for the USB device ID of Realtek RTL8159-based adapters, for which the product ID is 0x815a. Detect the RTL8159 as RTL_VER_17 and set it up. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-2-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add support for 10Gbit Link Speeds and EEEBirger Koblitz
The RTL8159 supports 10GBit Link speeds. Add support for this speed in the setup and setting/getting through ethtool. Also add 10GBit EEE. Add functionality for setup and ethtool get/set methods. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-1-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net: ethernet: cortina: Drop half-assembled SKBAndreas Haarmann-Thiemann
In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when gmac_get_queue_page() returns NULL for the second page of a multi-page fragment, the driver logs an error and continues — but does not free the partially assembled skb that was being assembled via napi_build_skb() / napi_get_frags(). Free the in-progress partially assembled skb via napi_free_frags() and increase the number of dropped frames appropriately and assign the skb pointer NULL to make sure it is not lingering around, matching the pattern already used elsewhere in the driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Andreas Haarmann-Thiemann <eitschman@nebelreich.de> Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260505-gemini-ethernet-fix-v2-1-997c31d06079@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report stop and wake TX queue statsGal Pressman
Report TX queue stop and wake statistics via the netdev queue stats API by mapping the existing stopped and wake counters to the stop and wake fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-19 02:59:04 +0000