summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2025-11-10bonding: fix mii_status when slave is downNicolas Dichtel1-2/+3
netif_carrier_ok() doesn't check if the slave is up. Before the below commit, netif_running() was also checked. Fixes: 23a6037ce76c ("bonding: Remove support for use_carrier") Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20251106180252.3974772-1-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10gve: Default to max_rx_buffer_size for DQO if device supportedAnkit Garg1-0/+4
Change the driver's default behavior to prefer the largest available RX buffer length supported by the device for DQO format, rather than always using the hardcoded 2K default. Previously, the driver would initialize with `GVE_DEFAULT_RX_BUFFER_SIZE` (2K), even if the device advertised support for a larger length (e.g., 4K). Performance observations: - With LRO disabled, we observed >10% improvement in RX single stream throughput when MTU >=2048. - With LRO enabled, we observed >10% improvement in RX single stream throughput when MTU >=1460. - No regressions were observed. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251106192746.243525-5-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10gve: Allow ethtool to configure rx_buf_lenAnkit Garg3-1/+60
Add support for getting and setting the RX buffer length via the ethtool ring parameters (`ethtool -g`/`-G`). The driver restricts the allowed buffer length to 2048 (SZ_2K) by default and allows 4096 (SZ_4K) based on device options. As XDP is only supported when the `rx_buf_len` is 2048, the driver now enforces this in two places: 1. In `gve_xdp_set`, rejecting XDP programs if the current buffer length is not 2048. 2. In `gve_set_rx_buf_len_config`, rejecting buffer length changes if XDP is loaded and the new length is not 2048. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251106192746.243525-4-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10gve: Use extack to log xdp config verification errorsAnkit Garg1-9/+15
Plumb extack as it allows us to send more detailed error messages back and append 'gve' suffix to method name per convention. NL_SET_ERR_MSG_FMT_MOD doesn't support format string longer than 80 chars so keeping netdev warning with actual queue count details. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251106192746.243525-3-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10gve: Decouple header split from RX buffer lengthAnkit Garg3-15/+0
Previously, enabling header split via `gve_set_hsplit_config` also implicitly changed the RX buffer length to 4K (if supported by the device). This coupled two settings that should be orthogonal; this patch removes that side effect. After this change, `gve_set_hsplit_config` only toggles the header split configuration. The RX buffer length is no longer affected and must be configured independently. Signed-off-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Link: https://patch.msgid.link/20251106192746.243525-2-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: use ->set_phy_intf_sel()Russell King (Oracle)1-21/+10
Rather than placing the phy_intf_sel() setup in the ->init() method, move it to the new ->set_phy_intf_sel() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHqY-0000000Djrn-1D6H@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: pass ingenic_mac struct rather than plat_datRussell King (Oracle)1-18/+7
It no longer makes sense to pass a pointer to struct plat_stmmacenet_data when calling the set_mode() methods to only use it to get a pointer to the ingenic_mac structure that we already had in the caller. Simplify this by passing the struct ingenic_mac pointer. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHqT-0000000Djrh-0ka3@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: simplify x2000 mac_set_mode()Russell King (Oracle)1-20/+6
As per the previous commit, we have validated that the phy_intf_sel value is one that is permissible for this SoC, so there is no need to handle invalid PHY interface modes. We can also apply the other configuration based upon the phy_intf_sel value rather than the PHY interface mode. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHqO-0000000Djrb-0DPN@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: simplify mac_set_mode() methodsRussell King (Oracle)1-48/+2
x1000, x1600 and x1830 only accept RMII mode. PHY_INTF_SEL_RMII is only selected with PHY_INTERFACE_MODE_RMII, and PHY_INTF_SEL_RMII has been validated by the SoC's .valid_phy_intf_sel bitmask. Thus, checking the interface mode in these functions becomes unnecessary. Remove these. jz4775 is similar, except for a greater set of PHY_INTF_SEL_x valies. Also remove the switch statement here. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHqI-0000000DjrV-3ygL@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: move "MAC PHY control register" debugRussell King (Oracle)1-15/+3
Move the printing of the MAC PHY control register interface mode setting into ingenic_set_phy_intf_sel(), and use phy_modes() to print the string rather than using the enum name. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHqD-0000000DjrP-3aaU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: use stmmac_get_phy_intf_sel()Russell King (Oracle)1-21/+34
Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the phy_intf_sel value, validate the result against the SoC specific supported phy_intf_sel values, and pass into the SoC specific set_mode() methods, replacing the local phy_intf_sel variable. This provides the value for the MACPHYC_PHY_INFT_MASK field. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHq8-0000000DjrJ-2NRK@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: prep PHY_INTF_SEL_x field after switch()Russell King (Oracle)1-11/+23
Move the preparation of the PHY_INTF_SEL_x bitfield out of the switch() statement such that it only appears once. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHq3-0000000DjrD-1u8O@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: use PHY_INTF_SEL_x directlyRussell King (Oracle)1-12/+8
Use the PHY_INTF_SEL_x values directly in each of the mac_set_mode methods rather than the driver private MACPHYC_PHY_INFT_x definitions. Remove the MACPHYC_PHY_INFT_x definitions. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHpy-0000000Djr7-1R1m@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: use PHY_INTF_SEL_x to select PHY interfaceRussell King (Oracle)1-4/+4
Use the common dwmac definitions for the PHY interface selection field. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHpt-0000000Djr1-0wwr@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: simplify jz4775 mac_set_mode()Russell King (Oracle)1-8/+6
All paths configure the transmit clock as an input. Move this out of the switch() statement to simplify the code. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHpo-0000000Djqv-0RD4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: stmmac: ingenic: move ingenic_mac_init()Russell King (Oracle)1-14/+14
Move ingenic_mac_init() to between variant specific set_mode() implementations and ingenic_mac_probe(). No code changes. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vHHpi-0000000Djqp-4910@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10usbnet: Add support for Byte Queue Limits (BQL)Simon Schippers1-0/+11
In the current implementation, usbnet uses a fixed tx_qlen of: USB2: 60 * 1518 bytes = 91.08 KB USB3: 60 * 5 * 1518 bytes = 454.80 KB Such large transmit queues can be problematic, especially for cellular modems. For example, with a typical celluar link speed of 10 Mbit/s, a fully occupied USB3 transmit queue results in: 454.80 KB / (10 Mbit/s / 8 bit/byte) = 363.84 ms of additional latency. This patch adds support for Byte Queue Limits (BQL) [1] to dynamically manage the transmit queue size and reduce latency without sacrificing throughput. Testing was performed on various devices using the usbnet driver for packet transmission: - DELOCK 66045: USB3 to 2.5 GbE adapter (ax88179_178a) - DELOCK 61969: USB2 to 1 GbE adapter (asix) - Quectel RM520: 5G modem (qmi_wwan) - USB2 Android tethering (cdc_ncm) No performance degradation was observed for iperf3 TCP or UDP traffic, while latency for a prioritized ping application was significantly reduced. For example, using the USB3 to 2.5 GbE adapter, which was fully utilized by iperf3 UDP traffic, the prioritized ping was improved from 1.6 ms to 0.6 ms. With the same setup but with a 100 Mbit/s Ethernet connection, the prioritized ping was improved from 35 ms to 5 ms. [1] https://lwn.net/Articles/469652/ Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20251106175615.26948-1-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10tg3: Fix num of RX queues being reported by ethtoolBreno Leitao1-1/+1
Using num_online_cpus() to report number of queues is actually not correct, as reported by Michael[1]. netif_get_num_default_rss_queues() was used to replace num_online_cpus() in the past, but tg3 ethtool callbacks didn't get converted. Doing it now. Link: https://lore.kernel.org/all/CACKFLim7ruspmqvjr6bNRq5Z_XXVk3vVaLZOons7kMCzsEG23A@mail.gmail.com/#t [1] Signed-off-by: Breno Leitao <leitao@debian.org> Suggested-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20251107-tg3_counts-v1-1-337fe5c8ccb7@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: add support for bcm63xx ARL entry formatJonas Gorski3-7/+61
The ARL registers of BCM63XX embedded switches are somewhat unique. The normal ARL table access registers have the same format as BCM5389, but the ARL search registers differ: * SRCH_CTL is at the same offset of BCM5389, but 16 bits wide. It does not have more fields, just needs to be accessed by a 16 bit read. * SRCH_RSLT_MACVID and SRCH_RSLT are aligned to 32 bit, and have shifted offsets. * SRCH_RSLT has a different format than the normal ARL data entry register. * There is only one set of ENTRY_N registers, implying a 1 bin layout. So add appropriate ops for bcm63xx and let it use it. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-9-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: add support for 5389/5397/5398 ARL entry formatJonas Gorski3-3/+89
BCM5389, BCM5397 and BCM5398 use a different ARL entry format with just a 16 bit fwdentry register, as well as different search control and data offsets. So add appropriate ops for them and switch those chips to use them. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-8-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: move ARL entry functions into ops structJonas Gorski2-21/+76
Now that the differences in ARL entry formats are neatly contained into functions per chip family, wrap them into an ops struct and add wrapper functions to access them. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-7-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: split reading search entry into their own functionsJonas Gorski1-18/+38
Split reading search entries into a function for each format. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-6-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: provide accessors for accessing ARL_SRCH_CTLJonas Gorski1-13/+24
In order to more easily support more formats, move accessing ARL_SRCH_CTL into helper functions to contain the differences. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-5-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: move writing ARL entries into their own functionsJonas Gorski1-12/+26
Move writing ARL entries into individual functions for each format. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-4-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: move reading ARL entries into their own functionJonas Gorski1-46/+23
Instead of duplicating the whole code iterating over all bins for BCM5325, factor out reading and parsing the entry into its own functions, and name it the modern one after the first chip with that ARL format, (BCM53)95. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: dsa: b53: b53_arl_read{,25}(): use the entry for comparisionJonas Gorski1-12/+10
Align the b53_arl_read{,25}() functions by consistently using the parsed arl entry instead of parsing the raw registers again. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251107080749.26936-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-10net: ravb: Correct bad check of timestamp control flagsNiklas Söderlund1-2/+2
When converting the Renesas network drivers to use flags from enum hwtstamp_rx_filters to control when to timestamp packages instead of a driver specific schema with bit-wise flags an error was made. The bit-wise driver specific flags correct logic to set get_ts was: q: RAVB_BE + tstamp_rx_ctrl: 0 => 0 q: RAVB_NC + tstamp_rx_ctrl: 0 => 0 q: RAVB_BE + tstamp_rx_ctrl: RAVB_RXTSTAMP_TYPE_V2_L2_EVENT => 0 q: RAVB_NC + tstamp_rx_ctrl: RAVB_RXTSTAMP_TYPE_V2_L2_EVENT => 1 q: RAVB_BE + tstamp_rx_ctrl: RAVB_RXTSTAMP_TYPE_ALL => 1 q: RAVB_NC + tstamp_rx_ctrl: RAVB_RXTSTAMP_TYPE_ALL => 1 The converted logic to use enum flags mapped tstamp_rx_ctrl as 0 to HWTSTAMP_FILTER_NONE RAVB_RXTSTAMP_TYPE_V2_L2_EVENT to HWTSTAMP_FILTER_PTP_V2_L2_EVENT RAVB_RXTSTAMP_TYPE_ALL to HWTSTAMP_FILTER_ALL But the logic was incorrectly changed to: q: RAVB_BE + tstamp_rx_ctrl: HWTSTAMP_FILTER_NONE => 1 (error) q: RAVB_NC + tstamp_rx_ctrl: HWTSTAMP_FILTER_NONE => 0 q: RAVB_BE + tstamp_rx_ctrl: HWTSTAMP_FILTER_PTP_V2_L2_EVENT => 0 q: RAVB_NC + tstamp_rx_ctrl: HWTSTAMP_FILTER_PTP_V2_L2_EVENT => 1 q: RAVB_BE + tstamp_rx_ctrl: HWTSTAMP_FILTER_ALL => 1 q: RAVB_NC + tstamp_rx_ctrl: HWTSTAMP_FILTER_ALL => 0 (error) This change restores the converted flag check to the correct logic of the bit-wise driver specific flags. Reported-by: Simon Horman <horms@kernel.org> Closes: https://lore.kernel.org/linux-renesas-soc/aQ4xSv9629XF-Bt3@horms.kernel.org/ Fixes: 16e2e6cf75e6 ("net: ravb: Use common defines for time stamping control") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251107200100.3637869-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-09net/mlx5: fs, set non default device per namespacePatrisious Haddad2-18/+56
Add mlx5_fs_set_root_dev() function which swaps the root namespace core device with another one for a given table_type. It is intended for usage only by RDMA_TRANSPORT tables in case of LAG configuration, to allow the creation of tables during LAG always through the LAG master device, which is valid since during LAG the master is allowed to manage the RDMA_TRANSPORT tables of its slaves. In addition move the table_type enum to global include to allow its use in a downstream patch in the RDMA driver. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-3-98bb707b5d57@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-11-09net/mlx5: fs, Add other_eswitch support for steering tablesPatrisious Haddad3-10/+40
Add other_eswitch support which allows flow tables creation above vports that reside on different esw managers. The new flag MLX5_FLOW_TABLE_OTHER_ESWITCH indicates if the esw_owner_vhca_id attribute is supported. Note that this is only supported if the Advanced-RDMA cap- rdma_transport_manager_other_eswitch is set. And it is the caller responsibility to check that. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20251029-support-other-eswitch-v1-2-98bb707b5d57@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-11-09net/mlx5: Add direct ST mode support for RDMAYishai Hadas1-4/+25
Add support for direct ST mode where ST Table Location equals PCI_TPH_LOC_NONE. In that case, no steering table exists, the steering tag itself will be used directly by the SW, FW, HW from the mkey. This enables RDMA users to use the current exposed APIs to work in direct mode. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20251027-st-direct-mode-v1-2-e0ad953866b6@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-11-07Merge branch '40GbE' of ↵Jakub Kicinski13-137/+2027
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-11-06 (i40, ice, iavf) Mohammad Heib introduces a new devlink parameter, max_mac_per_vf, for controlling the maximum number of MAC address filters allowed by a VF. This allows administrators to control the VF behavior in a more nuanced manner. Aleksandr and Przemek add support for Receive Side Scaling of GTP to iAVF for VFs running on E800 series ice hardware. This improves performance and scalability for virtualized network functions in 5G and LTE deployments. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: iavf: add RSS support for GTP protocol via ethtool ice: Extend PTYPE bitmap coverage for GTP encapsulated flows ice: improve TCAM priority handling for RSS profiles ice: implement GTP RSS context tracking and configuration ice: add virtchnl definitions and static data for GTP RSS ice: add flow parsing for GTP and new protocol field support i40e: support generic devlink param "max_mac_per_vf" devlink: Add new "max_mac_per_vf" generic device param ==================== Link: https://patch.msgid.link/20251106225321.1609605-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: sti: use ->set_phy_intf_sel()Russell King (Oracle)1-16/+9
Rather than placing the phy_intf_sel() setup in the ->init() method, move it to the new ->set_phy_intf_sel() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5o-0000000DhQn-34JE@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: sti: use stmmac_get_phy_intf_sel()Russell King (Oracle)1-13/+9
Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the phy_intf_sel value, validate the result and use that to set the control register to select the operating mode for the DWMAC core. Note that when an unsupported interface mode is used, the array would decode this to PHY_INTF_SEL_GMII_MII, so preserve this behaviour. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5j-0000000DhQh-2e0x@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: sti: use PHY_INTF_SEL_x directlyRussell King (Oracle)1-15/+12
Use the PHY_INTF_SEL_x values directly rather than the driver private ETH_PHY_SEL_x values. Move the FIELD_PREP() into sti_dwmac_set_mode(). Use dwmac->interface directly. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5e-0000000DhQb-2B7I@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: sti: use PHY_INTF_SEL_x to select PHY interfaceRussell King (Oracle)1-5/+7
Use the common dwmac definitions for the PHY interface selection field, adding MII_PHY_SEL_VAL() temporarily to avoid line wrapping. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5Z-0000000DhQV-1e2l@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: lpc18xx: use ->set_phy_intf_sel()Russell King (Oracle)1-14/+22
Move the configuration of the dwmac PHY interface selection to the new ->set_phy_intf_sel() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5U-0000000DhQP-19Hd@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: lpc18xx: validate phy_intf_selRussell King (Oracle)1-4/+3
Validate the phy_intf_sel value rather than the PHY interface mode. This will allow us to transition to the ->set_phy_intf_sel() method. Note that this will allow GMII as well as MII as the phy_intf_sel value is the same for both. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5P-0000000DhQJ-0Oi3@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: lpc18xx: use stmmac_get_phy_intf_sel()Russell King (Oracle)1-5/+4
Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the phy_intf_sel value, and use the result to program the ethernet mode. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5J-0000000DhQD-46Ob@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: lpc18xx: use PHY_INTF_SEL_x directlyRussell King (Oracle)1-5/+3
Use the PHY_INTF_SEL_x values directly rather than the driver private LPC18XX_CREG_CREG6_ETHMODE_x definitions, and convert LPC18XX_CREG_CREG6_ETHMODE_MASK to use GENMASK(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy5E-0000000DhQ7-3cuy@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: stmmac: lpc18xx: convert to PHY_INTF_SEL_xRussell King (Oracle)1-2/+2
Use the common dwmac definitions for the PHY interface selection field. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vGy59-0000000DhQ1-393H@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: phy: micrel: lan8814 fix reset of the QSGMII interfaceHoratiu Vultur1-6/+6
The lan8814 is a quad-phy and it is using QSGMII towards the MAC. The problem is that everytime when one of the ports is configured then the PCS is reseted for all the PHYs. Meaning that the other ports can loose traffic until the link is establish again. To fix this, do the reset one time for the entire PHY package. Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Divya Koppera <Divya.Koppera@microchip.com > Link: https://patch.msgid.link/20251106090637.2030625-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: fec: correct rx_bytes statistic for the case SHIFT16 is setWei Fang1-0/+2
Two additional bytes in front of each frame received into the RX FIFO if SHIFT16 is set, so we need to subtract the extra two bytes from pkt_len to correct the statistic of rx_bytes. Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251106021421.2096585-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07netdevsim: implement psp device statsDaniel Zahka2-0/+32
For now only tx/rx packets/bytes are reported. This is not compliant with the PSP Architecture Specification. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251106002608.1578518-6-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net/mlx5e: Add PSP stats support for Rx/Tx flowsJakub Kicinski4-15/+240
Add all statistics described under the "Implementation Requirements" section of the PSP Architecture Specification: Rx successfully decrypted PSP packets: psp_rx_pkts : Number of packets decrypted successfully psp_rx_bytes : Number of bytes decrypted successfully Rx PSP authentication failure statistics: psp_rx_pkts_auth_fail : Number of PSP packets that failed authentication psp_rx_bytes_auth_fail : Number of PSP bytes that failed authentication Rx PSP bad frame error statistics: psp_rx_pkts_frame_err; psp_rx_bytes_frame_err; Rx PSP drop statistics: psp_rx_pkts_drop : Number of PSP packets dropped psp_rx_bytes_drop : Number of PSP bytes dropped Tx successfully encrypted PSP packets: psp_tx_pkts : Number of packets encrypted successfully psp_tx_bytes : Number of bytes encrypted successfully Tx drops: tx_drop : Number of misc psp related drops The above can be seen using the ynl cli: ./pyynl/cli.py --spec netlink/specs/psp.yaml --dump get-stats Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251106002608.1578518-5-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: phy: fixed_phy: shrink size of struct fixed_phy_statusHeiner Kallweit1-1/+1
All three members are effectively of type bool, so make this explicit and shrink size of struct fixed_phy_status. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/9eca3d7e-fa64-4724-8fdc-f2c1a8f2ae8f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: phy: microchip_t1s:: add cable diagnostic support for LAN867x Rev.D0Parthiban Veerasooran1-0/+2
Enable Open Alliance TC14 (OATC14) 10Base-T1S cable diagnostic feature for Microchip LAN867x Rev.D0 PHY by implementing `cable_test_start` and `cable_test_get_status` using the generic C45 functions. This allows the `ethtool` utility to perform cable diagnostic tests directly on the PHY, improving network troubleshooting and maintenance. Signed-off-by: Parthiban Veerasooran <parthiban.veerasooran@microchip.com> Link: https://patch.msgid.link/20251105051213.50443-3-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: phy: phy-c45: add OATC14 10BASE-T1S PHY cable diagnostic supportParthiban Veerasooran2-0/+158
Add support for Open Alliance TC14 (OATC14) 10BASE-T1S PHYs cable diagnostic feature. This patch implements: - genphy_c45_oatc14_cable_test_start() to initiate a cable test - genphy_c45_oatc14_cable_test_get_status() to retrieve test results - Helper function to map PHY cable test status to ethtool result codes - Function declarations and exports for use by PHY drivers This enables ethtool to report ok, open, short, and undetectable cable conditions on OATC14 10Base-T1S PHYs. Open Alliance TC14 10BASE-T1S Advanced Diagnostic PHY Features Specification ref: https://opensig.org/wp-content/uploads/2025/06/OPEN_Alliance_10BASE-T1S_Advanced_PHY_features_for-automotive_Ethernet_V2.1b.pdf Signed-off-by: Parthiban Veerasooran <parthiban.veerasooran@microchip.com> Link: https://patch.msgid.link/20251105051213.50443-2-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: mana: Fix incorrect speed reported by debugfsErni Sri Satya Vennela1-1/+1
Once the netshaper is created for MANA, the current bandwidth is reported in debugfs like this: $ sudo ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/net_shaper.yaml \ --do set \ --json '{"ifindex":'3', "handle":{ "scope": "netdev", "id":'1' }, "bw-max": 200000000 }' None $ sudo cat /sys/kernel/debug/mana/1/vport0/current_speed 200 After the shaper is deleted, it is expected to report the maximum speed supported by the SKU. But currently it is reporting 0, which is incorrect. Fix this inconsistency, by resetting apc->speed to apc->max_speed during deletion of the shaper object. This will improve readability and debuggability. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1762369468-32570-1-git-send-email-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-07net: airoha: Add the capability to consume out-of-order DMA tx descriptorsLorenzo Bianconi2-47/+45
EN7581 and AN7583 SoCs are capable of DMA mapping non-linear tx skbs on non-consecutive DMA descriptors. This feature is useful when multiple flows are queued on the same hw tx queue since it allows to fully utilize the available tx DMA descriptors and to avoid the starvation of high-priority flow we have in the current codebase due to head-of-line blocking introduced by low-priority flows. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251106-airoha-tx-linked-list-v2-1-0706d4a322bd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: ravb: Use common defines for time stamping controlNiklas Söderlund2-37/+14
Instead of translating to/from driver specific flags for packet time stamp control use the common flags directly. This simplifies the driver as the translating code can be removed while at the same time making it clear the flags are not flags written to hardware registers. The change from a device specific bit-field track variable to the common enum datatypes forces us to touch the ravb_rx_rcar_hwstamp() in a non trivial way. To make this cleaner and easier to understand expand the nested conditions. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-8-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>