summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-11-19net/mlx5: Move SF dev table notifier registration outside the PF devlink lockCosmin Ratiu
This completes the previous patches by moving notifier registration for SF dev tables outside the devlink locked critical section in mlx5_init_one() / mlx5_uninit_one() and into the mlx5_mdev_init() / mlx5_mdev_uninit() functions. This is only done for non-SFs, since SFs do not have a SF HW table themselves. After this patch, notifiers can grab the PF devlink lock (soon to be necessary) without creating a locking cycle. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-7-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net/mlx5: Move the SF table notifiers outside the devlink lockCosmin Ratiu
Move the SF table notifiers registration/unregistration outside of mlx5_init_one() / mlx5_uninit_one() and into the mlx5_mdev_init() / mlx5_mdev_uninit() functions. This is only done for non-SFs, since SFs do not have a SF table themselves and thus don't need notifiers. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net/mlx5: Move the SF HW table notifier outside the devlink lockCosmin Ratiu
Move the SF HW table notifier registration/unregistration outside of mlx5_init_one() / mlx5_uninit_one() and into the mlx5_mdev_init() / mlx5_mdev_uninit() functions. This is only done for non-SFs, since SFs do not have a SF HW table themselves. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net/mlx5: Move the vhca event notifier outside of the devlink lockCosmin Ratiu
The vhca event notifier consists of an atomic notifier for vhca state changes (used for SF events), multiple workqueues and a blocking notifier chain for delivering the vhca state change events for further processing. This patch moves the vhca notifier head outside of mlx5_init_one() / mlx5_uninit_one() and into the mlx5_mdev_init() / mlx5_mdev_uninit() functions. This allows called notifiers to grab the PF devlink lock which was previously impossible because it would create a circular lock dependency. mlx5_vhca_event_stop() is now called earlier in the cleanup phase and flushes the workqueues to ensure that after the call, there are no pending events. This simplifies the cleanup flow for vhca event consumers. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net/mlx5: Move the esw mode notifier chain outside the devlink lockCosmin Ratiu
The esw mode change notifier chain is initialized/cleaned up in mlx5_init_one() / mlx5_uninit_one() with the devlink lock held. Move the notifier head from the eswitch struct into mlx5_priv directly, and initialize it outside the critical section. This will allow notifier registration to happen earlier in the init procedure in subsequent patches. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net/mlx5: Initialize events outside devlink lockCosmin Ratiu
Move event init/cleanup outside of mlx5_init_one() / mlx5_uninit_one() and into the mlx5_mdev_init() / mlx5_mdev_uninit() functions. By doing this, we avoid the events being reinitialized on devlink reload and, more importantly, the events->sw_nh notifier chain becomes available earlier in the init procedure, which will be used in subsequent patches. This makes sense because the events struct is pure software, independent of any HW details. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763325940-1231508-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: create rtl8211f_config_phy_eee() helperVladimir Oltean
To simplify the rtl8211f_config_init() control flow and get rid of "early" returns for PHYs where the PHYCR2 register is absent, move the entire logic sub-block that deals with disabling PHY-mode EEE to a separate function. There, it is much more obvious what the early "return 0" skips, and it becomes more difficult to accidentally skip unintended stuff. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20251117234033.345679-7-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: eliminate priv->phycr1 variableVladimir Oltean
Previous changes have replaced the machine-level priv->phycr2 with a high-level priv->disable_clk_out. This created a discrepancy with priv->phycr1 which is resolved here, for uniformity. One advantage of this new implementation is that we don't read priv->phycr1 in rtl821x_probe() if we're never going to modify it. We never test the positive return code from phy_modify_mmd_changed(), so we could just as well use phy_modify_mmd(). I took the ALDPS feature description from commit d90db36a9e74 ("net: phy: realtek: add dt property to enable ALDPS mode") and transformed it into a function comment - the feature is sufficiently non-obvious to deserve that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251117234033.345679-6-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: allow CLKOUT to be disabled on RTL8211F(D)(I)-VD-CGVladimir Oltean
Add CLKOUT disable support for RTL8211F(D)(I)-VD-CG. Like with other PHY variants, this feature might be requested by customers when the clock output is not used, in order to reduce electromagnetic interference (EMI). In the common driver, the CLKOUT configuration is done through PHYCR2. The RTL_8211FVD_PHYID is singled out as not having that register, and execution in rtl8211f_config_init() returns early after commit 2c67301584f2 ("net: phy: realtek: Avoid PHYCR2 access if PHYCR2 not present"). But actually CLKOUT is configured through a different register for this PHY. Instead of pretending this is PHYCR2 (which it is not), just add some code for modifying this register inside the rtl8211f_disable_clk_out() function, and move that outside the code portion that runs only if PHYCR2 exists. In practice this reorders the PHYCR2 writes to disable PHY-mode EEE and to disable the CLKOUT for the normal RTL8211F variants, but this should be perfectly fine. It was not noted that RTL8211F(D)(I)-VD-CG would need a genphy_soft_reset() call after disabling the CLKOUT. Despite that, we do it out of caution and for symmetry with the other RTL8211F models. Co-developed-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251117234033.345679-5-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: eliminate has_phycr2 variableVladimir Oltean
This variable is assigned in rtl821x_probe() and used in rtl8211f_config_init(), which is more complex than it needs to be. Simply testing the same condition from rtl821x_probe() in rtl8211f_config_init() yields the same result (the PHY driver ID is a runtime invariant), but with one temporary variable less. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251117234033.345679-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: eliminate priv->phycr2 variableVladimir Oltean
The RTL8211F(D)(I)-VD-CG PHY also has support for disabling the CLKOUT, and we'd like to introduce the "realtek,clkout-disable" property for that. But it isn't done through the PHYCR2 register, and it becomes awkward to have the driver pretend that it is. So just replace the machine-level "u16 phycr2" variable with a logical "bool disable_clk_out", which scales better to the other PHY as well. The change is a complete functional equivalent. Before, if the device tree property was absent, priv->phycr2 would contain the RTL8211F_CLKOUT_EN bit as read from hardware. Now, we don't save priv->phycr2, but we just don't call phy_modify_paged() on it. Also, we can simply call phy_modify_paged() with the "set" argument to 0. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20251117234033.345679-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: phy: realtek: create rtl8211f_config_rgmii_delay()Vladimir Oltean
The control flow in rtl8211f_config_init() has some pitfalls which were probably unintended. Specifically it has an early return: switch (phydev->interface) { ... default: /* the rest of the modes imply leaving delay as is. */ return 0; } which exits the entire config_init() function. This means it also skips doing things such as disabling CLKOUT or disabling PHY-mode EEE. For the RTL8211FS, which uses PHY_INTERFACE_MODE_SGMII, this might be a problem. However, I don't know that it is, so there is no Fixes: tag. The issue was observed through code inspection. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251117234033.345679-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: vmxnet3: convert to use .get_rx_ring_countBreno Leitao
Convert the vmxnet3 driver to use the new .get_rx_ring_count ethtool operation instead of implementing .get_rxnfc solely for handling ETHTOOL_GRXRINGS command. This simplifies the code by removing the switch statement and replacing it with a direct return of the queue count. The new callback provides the same functionality in a more direct way, following the ongoing ethtool API modernization. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251118-vmxnet3_grxrings-v1-1-ed8abddd2d52@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: mana: Drop TX skb on post_work_request failure and unmap resourcesAditya Garg
Drop TX packets when posting the work request fails and ensure DMA mappings are always cleaned up. Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1763464269-10431-3-git-send-email-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: mana: Handle SKB if TX SGEs exceed hardware limitAditya Garg
The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs) per TX WQE. Exceeding this limit can cause TX failures. Add ndo_features_check() callback to validate SKB layout before transmission. For GSO SKBs that would exceed the hardware SGE limit, clear NETIF_F_GSO_MASK to enforce software segmentation in the stack. Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still exceed the SGE limit. Also, Add ethtool counter for SKBs linearized Co-developed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1763464269-10431-2-git-send-email-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19octeontx2-af: Skip TM tree print for disabled SQsAnshumali Gaur
Currently, the TM tree is printing all SQ topology including those which are not enabled, this results in redundant output for SQs which are not active. This patch adds a check in print_tm_tree() to skip printing the TM tree hierarchy if the SQ is not enabled. Signed-off-by: Anshumali Gaur <agaur@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251118054235.1599714-1-agaur@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: stmmac: stmmac_is_jumbo_frm() returns booleanRussell King (Oracle)
stmmac_is_jumbo_frm() returns whether the driver considers the frame size to be a jumbo frame, and thus returns 0/1 values. This is boolean, so convert it to return a boolean and use false/true instead. Also convert stmmac_xmit()'s is_jumbo to be bool, which causes several variables to be repositioned to keep it in reverse Christmas-tree order. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1vLIWW-0000000Ewkl-21Ia@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: stmmac: stmmac_is_jumbo_frm() len should be unsignedRussell King (Oracle)
stmmac_is_jumbo_frm() and the is_jumbo_frm() methods take skb->len which is an unsigned int. Avoid an implicit cast to "int" via the method parameter and then incorrectly doing signed comparisons on this unsigned value. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1vLIWR-0000000Ewkf-1Tdx@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19net: stmmac: convert priv->sph* to boolean and renameRussell King (Oracle)
priv->sph* only have 'true' and 'false' used with them, yet they are an int. Change their type to a bool, and rename to make their usage more clear. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1vLIDN-0000000Evur-2NLU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net/mlx5: Use EOPNOTSUPP instead of ENOTSUPPTariq Toukan
Per Documentation/dev-tools/checkpatch.rst, ENOTSUPP is not a standard error code and should be avoided. EOPNOTSUPP should be used instead. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/1763415729-1238421-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net/mlx5: Abort new commands if all command slots are stalledSaeed Mahameed
In case of a FW issue, FW might be not responding to FW commands, causing kernel lockout for a long period of time, e.g. rtnl_lock held while ethtool is trying to collect stats waiting for FW to respond to multiple commands, when all of them will timeout. While there's no immediate indication of the FW lockout, we can safely assume that something is wrong when all command slots are busy and in a timeout state and no FW completion was received on any of them. In such case, start immediately failing new commands. Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763415729-1238421-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net/mlx5: Remove redundant bw_share minimal value assignmentCarolina Jubran
Remove unnecessary logic that sets bw_share to minimal value, when parent has bw_share configured but nodes don't have min_rate. This check is redundant because the parent bandwidth acts as the upper bound regardless, and the firmware always enforces the topmost bandwidth constraint. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763415729-1238421-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net/mlx5e: Recover SQ on excessive PTP TX timestamp deltaCarolina Jubran
Extend the TX timestamp handler to recover the SQ when the difference between the port and CQE TX timestamps is abnormally large. The current logic aborts timestamp delivery if the delta exceeds 1/128 seconds, which matches the maximum expected packet interval in ptp4l. A larger delta makes the timestamps unreliable. This change adds recovery if the delta exceeds 0.5 seconds. Such a large gap should not occur in normal operation and indicates that firmware is stuck or metadata tracking is out of sync, leading to stale or mismatched timestamps. Recovering the SQ ensures forward progress and avoids silently dropping invalid timestamps. The timestamp handler now takes mlx5e_ptpsq directly to access both CQ stats and the recovery state. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763415729-1238421-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net/mlx5: Refactor EEPROM query error handling to return status separatelyGal Pressman
Matthew and Jakub reported [1] issues where inventory automation tools are calling EEPROM query repeatedly on a port that doesn't have an SFP connected, resulting in millions of error prints. Move MCIA register status extraction from the query functions to the callers, allowing use of extack reporting instead of a dmesg print when using the netlink API. [1] https://lore.kernel.org/netdev/20251028194011.39877-1-mattc@purestorage.com/ Cc: Matthew W Carlis <mattc@purestorage.com> Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763415729-1238421-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18net: dsa: ks8995: Fix incorrect OF match table nameAlok Tiwari
The driver declares an OF match table named ks8895_spi_of_match, even though it describes compatible strings for the KS8995 and related Micrel switches. This is a leftover typo, the correct name should match the chip family handled by this driver ks8995, and also match the variable used in spi_driver.of_match_table. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20251117095356.2099772-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18gve: Add Rx HWTS metadata to AF_XDP ZC modeTim Hostetler
By overlaying the struct gve_xdp_buff on top of the struct xdp_buff_xsk that AF_XDP utilizes, the driver records the 32 bit timestamp via the completion descriptor and the cached 64 bit NIC timestamp via gve_priv. The driver's implementation of xmo_rx_timestamp extends the timestamp to the full and up to date 64 bit timestamp and returns it to the user. gve_rx_xsk_dqo is modified to accept a pointer to the completion descriptor and no longer takes a buf_len explicitly as it can be pulled out of the descriptor. With this patch gve now supports bpf_xdp_metadata_rx_timestamp. Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251114211146.292068-5-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18gve: Prepare bpf_xdp_metadata_rx_timestamp supportTim Hostetler
Support populating XDP RX metadata with hardware RX timestamps. This patch utilizes the same underlying logic to calculate hardware timestamps as the regular RX path. xdp_metadata_ops is registered with the net_device in a future patch. gve_rx_calculate_hwtstamp was pulled out so as to not duplicate logic between gve_xdp_rx_timestamp and gve_rx_hwtstamp. Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251114211146.292068-4-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18gve: Wrap struct xdp_buffTim Hostetler
RX timestamping will need to keep track of extra temporary information per-packet. In preparation for this, introduce gve_xdp_buff to wrap the xdp_buff. This is similar in function to stmmac_xdp_buff and ice_xdp_buff. Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251114211146.292068-3-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18gve: Move ptp_schedule_worker to gve_init_clockTim Hostetler
Previously, gve had been only initializing ptp aux work when hardware timestamping was initialized through ndo_hwtsatmp_set. As this patch series introduces XDP hardware timestamp metadata which will require the ptp aux work, the work can't be gated on the kernel_hwtstamp_config being set and must be initialized elsewhere. For simplicity, ptp_schedule_worker is invoked right after the ptp_clock is registered with the kernel (which happens during gve_probe or following reset). The worker is scheduled in GVE_NIC_TS_SYNC_INTERVAL_MS as the synchronous call to gve_clock_nic_ts_read makes the worker redundant if scheduled immediately. If gve cannot read the device clock immediately, it errors out of gve_init_clock. Signed-off-by: Tim Hostetler <thostet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251114211146.292068-2-joshwash@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18net: phy: micrel: lan8814: Enable in-band auto-negotiationHoratiu Vultur
The lan8814 supports two interfaces towards the host (QSGMII and QUSGMII). Currently the lan8814 disables the auto-negotiation towards the host side. So, extend this to allow to configure to use in-band auto-negotiation. I have tested this only with the QSGMII interface. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20251114084224.3268928-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18net: stmmac: Disable EEE RX clock stop when VLAN is enabledOvidiu Panait
On the Renesas RZ/V2H EVK platform, where the stmmac MAC is connected to a Microchip KSZ9131RNXI PHY, creating or deleting VLAN interfaces may fail with timeouts: # ip link add link end1 name end1.5 type vlan id 5 15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter RTNETLINK answers: Device or resource busy Disabling EEE at runtime avoids the problem: # ethtool --set-eee end1 eee off # ip link add link end1 name end1.5 type vlan id 5 # ip link del end1.5 The stmmac hardware requires the receive clock to be running when writing certain registers, such as those used for MAC address configuration or VLAN filtering. However, by default the driver enables Energy Efficient Ethernet (EEE) and allows the PHY to stop the receive clock when the link is idle. As a result, the RX clock might be stopped when attempting to access these registers, leading to timeouts and other issues. Commit dd557266cf5fb ("net: stmmac: block PHY RXC clock-stop") addressed this issue for most register accesses by wrapping them in phylink_rx_clk_stop_block()/phylink_rx_clk_stop_unblock() calls. However, VLAN add/delete operations may be invoked with bottom halves disabled, where sleeping is not allowed, so using these helpers is not possible. Therefore, to fix this, disable the RX clock stop feature in the phylink configuration if VLAN features are set. This ensures the RX clock remains active and register accesses succeed during VLAN operations. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20251113112721.70500-3-ovidiu.panait.rb@renesas.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()Ovidiu Panait
When the "rx-vlan-filter" feature is enabled on a network device, the 8021q module automatically adds a VLAN 0 hardware filter when the device is brought administratively up. For stmmac, this causes vlan_add_hw_rx_fltr() to create a new entry for VID 0 in the mac_device_info->vlan_filter array, in the following format: VLAN_TAG_DATA_ETV | VLAN_TAG_DATA_VEN | vid Here, VLAN_TAG_DATA_VEN indicates that the hardware filter is enabled for that VID. However, on the delete path, vlan_del_hw_rx_fltr() searches the vlan_filter array by VID only, without verifying whether a VLAN entry is enabled. As a result, when the 8021q module attempts to remove VLAN 0, the function may mistakenly match a zero-initialized slot rather than the actual VLAN 0 entry, causing incorrect deletions and leaving stale entries in the hardware table. Fix this by verifying that the VLAN entry's enable bit (VLAN_TAG_DATA_VEN) is set before matching and deleting by VID. This ensures only active VLAN entries are removed and avoids leaving stale entries in the VLAN filter table, particularly for VLAN ID 0. Fixes: ed64639bc1e08 ("net: stmmac: Add support for VLAN Rx filtering") Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20251113112721.70500-2-ovidiu.panait.rb@renesas.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-17r8169: bail out from probe if fiber mode is detected on RTL8127AFHeiner Kallweit
It was reported that on a card with RTL8127AF (SFP + DAC) link-up isn't detected. Realtek hides the SFP behind the internal PHY, which isn't behaving fully compliance with clause 22 any longer in fiber mode. Due to not having access to chip documentation there isn't much I can do for now. Instead of silently failing to detect link-up in fiber mode, inform the user that fiber mode isn't support and bail out. The logic to detect fiber mode is borrowed from Realtek's r8127 driver. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/fab6605a-54e2-4f54-b194-11c2b9caaaa9@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: dwmac-sophgo: Add phy interface filterInochi Amaoto
As the SG2042 has an internal rx delay, the delay should be removed when initializing the mac, otherwise the phy will be misconfigurated. Fixes: 543009e2d4cd ("net: stmmac: dwmac-sophgo: Add support for Sophgo SG2042 SoC") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251114003805.494387-4-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: phy: Add helper for fixing RGMII PHY mode based on internal mac delayInochi Amaoto
The "phy-mode" property of devicetree indicates whether the PCB has delay now, which means the mac needs to modify the PHY mode based on whether there is an internal delay in the mac. This modification is similar for many ethernet drivers. To simplify code, define the helper phy_fix_phy_mode_for_mac_delays(speed, mac_txid, mac_rxid) to fix PHY mode based on whether mac adds internal delay. Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251114003805.494387-3-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: mana: Add standard counter rx_missed_errorsErni Sri Satya Vennela
Report standard counter stats->rx_missed_errors using hc_rx_discards_no_wqe from the hardware. Add a global workqueue to periodically run mana_query_gf_stats every 2 seconds to get the latest info in eth_stats and define a driver capability flag to notify hardware of the periodic queries. To avoid repeated failures and log flooding, the workqueue is not rescheduled if mana_query_gf_stats fails on HWC timeout error and the stats are reset to 0. Other errors are transient which will not need a VF reset for recovery. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1763120599-6331-3-git-send-email-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: mana: Move hardware counter stats from per-port to per-VF contextErni Sri Satya Vennela
Move hardware counter (HC) statistics from mana_port_context to mana_context to enable sharing stats across multiple network ports on the same MANA VF. Previously, each network port queried hardware counters independently using MANA_QUERY_GF_STAT command (GF = Generic Function stats from GDMA hardware), resulting in redundant queries when multiple ports existed on the same device. Isolate hardware counter stats by introducing mana_ethtool_hc_stats in mana_context and update the code to ensure all stats are properly reported via ethtool -S <interface>, maintaining consistency with previous behavior. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1763120599-6331-2-git-send-email-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: remove unnecessary .pkt_route queue initialisationRussell King (Oracle)
PCI drivers explicitly set .pkt_route to zero. However, as the struct is allocated using devm_kzalloc(), all members default to zero unless explicitly initialised. Thus, explicitly setting these to zero is unnecessary. Remove these. This leaves only stmmac_platform.c where this is explicitly initialised depending on DT properties. $ grep '\.pkt_route =' *.c dwmac-intel.c: plat->rx_queues_cfg[0].pkt_route = 0x0; dwmac-intel.c: plat->rx_queues_cfg[i].pkt_route = 0x0; dwmac-loongson.c: plat->rx_queues_cfg[0].pkt_route = 0x0; stmmac_main.c: if (priv->plat->rx_queues_cfg[queue].pkt_route == 0x0) stmmac_pci.c: plat->rx_queues_cfg[0].pkt_route = 0x0; stmmac_pci.c: plat->rx_queues_cfg[i].pkt_route = 0x0; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = PACKET_AVCPQ; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = PACKET_PTPQ; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = PACKET_DCBCPQ; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = PACKET_UPQ; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = PACKET_MCBCQ; stmmac_platform.c: plat->rx_queues_cfg[queue].pkt_route = 0x0; Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjf-0000000EVkO-1ZaO@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: remove unnecessary .prio queue initialisationRussell King (Oracle)
stmmac_platform.c explicitly sets .prio to zero if the snps,priority property is not present in DT for the queue. However, as the struct is allocated using devm_kzalloc(), all members default to zero unless explicitly initialised, and of_property_read_u32() will not write to its argument if the property is not found. Thus, explicitly setting these to zero is unnecessary. Remove these. $ grep '\.prio =' *.c stmmac_platform.c: plat->rx_queues_cfg[queue].prio = 0; stmmac_platform.c: plat->tx_queues_cfg[queue].prio = 0; Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvja-0000000EVkI-0zUH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: remove unnecessary .use_prio queue initialisationRussell King (Oracle)
Several drivers (see below) explicitly set the queue .use_prio configuration to false. However, as this structure is allocated using devm_kzalloc(), all members default to zero unless otherwise explicitly initialised. .use_prio isn't, so defaults to false. Remove these unnecessary initialisations, leaving stmmac_platform.c as the only file that .use_prio is set true. $ grep 'use_prio =' *.c dwmac-intel.c: plat->tx_queues_cfg[0].use_prio = false; dwmac-intel.c: plat->rx_queues_cfg[0].use_prio = false; dwmac-intel.c: plat->rx_queues_cfg[i].use_prio = false; dwmac-intel.c: plat->tx_queues_cfg[i].use_prio = false; dwmac-loongson.c: plat->tx_queues_cfg[0].use_prio = false; dwmac-loongson.c: plat->rx_queues_cfg[0].use_prio = false; stmmac_pci.c: plat->tx_queues_cfg[0].use_prio = false; stmmac_pci.c: plat->rx_queues_cfg[0].use_prio = false; stmmac_pci.c: plat->tx_queues_cfg[i].use_prio = false; stmmac_pci.c: plat->rx_queues_cfg[i].use_prio = false; stmmac_platform.c: plat->rx_queues_cfg[queue].use_prio = false; stmmac_platform.c: plat->rx_queues_cfg[queue].use_prio = true; stmmac_platform.c: plat->tx_queues_cfg[queue].use_prio = false; stmmac_platform.c: plat->tx_queues_cfg[queue].use_prio = true; Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjV-0000000EVkC-0WAV@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: setup default RX channel map in stmmac_plat_dat_alloc()Russell King (Oracle)
Setup the default 1:1 RX channel map in stmmac_plat_dat_alloc() and remove 1:1 initialisations from platform glue drivers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjQ-0000000EVk6-05z7@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of queues_to_use to stmmac_plat_dat_alloc()Russell King (Oracle)
Move the default initialisation of plat_dat->tx_queues_to_use and plat_dat->rx_queues_to_use to 1 to stmmac_plat_dat_alloc(). This means platform glue only needs to override this if different. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjK-0000000EVk0-3qb2@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of unicast_filter_entries to ↵Russell King (Oracle)
stmmac_plat_dat_alloc() Move the default initialisation of plat_dat->unicast_filter_entries to 1 to stmmac_plat_dat_alloc(). This means platform glue only needs to override this if different. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjF-0000000EVju-3LfS@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of multicast_filter_bins to ↵Russell King (Oracle)
stmmac_plat_dat_alloc() Move the default initialisation of plat_dat->multicast_filter_bins to HASH_TABLE_SIZE to stmmac_plat_dat_alloc(). This means platform glue only needs to override this if different. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvjA-0000000EVjo-2qVn@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of maxmtu to stmmac_plat_dat_alloc()Russell King (Oracle)
Move the default initialisation of plat_dat->maxmtu to JUMBO_LEN to stmmac_plat_dat_alloc(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvj5-0000000EVji-2EYA@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of clk_csr to stmmac_plat_dat_alloc()Russell King (Oracle)
Move the default initialisation of plat_dat->clk_csr to stmmac_plat_dat_alloc(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJvj0-0000000EVjb-1jDh@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: move initialisation of phy_addr to stmmac_plat_dat_alloc()Russell King (Oracle)
Move the default initialisation of plat_dat->phy_addr to stmmac_plat_dat_alloc(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJviv-0000000EVjV-1CLF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17net: stmmac: add stmmac_plat_dat_alloc()Russell King (Oracle)
Add a function to allocate and initialise the plat_stmmacenet_data structure with default values. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vJviq-0000000EVjP-0c0l@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17qede: convert to use ndo_hwtstamp callbacksVadim Fedorenko
The driver implemented SIOCSHWTSTAMP ioctl cmd only, but it stores configuration in private structure, so it can be reported back to users. Implement both ndo_hwtstamp_set and ndo_hwtstamp_set callbacks. ndo_hwtstamp_set implements a check of unsupported 1-step timestamping and qede_ptp_cfg_filters() becomes void as it cannot fail anymore. Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251116094610.3932005-3-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17bnx2x: convert to use ndo_hwtstamp callbacksVadim Fedorenko
The driver implemented SIOCSHWTSTAMP ioctl command only, but at the same time it has configuration stored in a private structure. Implement both ndo_hwtstamp_set and ndo_hwtstamp_get callback using stored info. ndo_hwtstamp_set callback implements a check for unsupported 1-step timestamping. The same check is removed from bnx2x_configure_ptp_filters function as it's not needed anymore. Another call site of bnx2x_configure_ptp_filters has hwtstamp_ioctl_called guard. Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251116094610.3932005-2-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>