summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-01-16netdevsim: add HDS featureTaehee Yoo3-1/+23
HDS options(tcp-data-split, hds-thresh) have dependencies between other features like XDP. Basic dependencies are checked in the core API. netdevsim is very useful to check basic dependencies. The default tcp-data-split mode is UNKNOWN but netdevsim driver returns ENABLED when ethtool dumps tcp-data-split mode. The default value of HDS threshold is 0 and the maximum value is 1024. ethtool shows like this. ethtool -g eni1np1 Ring parameters for eni1np1: Pre-set maximums: ... HDS thresh: 1024 Current hardware settings: ... TCP data split: on HDS thresh: 0 ethtool -G eni1np1 tcp-data-split on hds-thresh 1024 ethtool -g eni1np1 Ring parameters for eni1np1: Pre-set maximums: ... HDS thresh: 1024 Current hardware settings: ... TCP data split: on HDS thresh: 1024 Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-10-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16bnxt_en: add support for hds-thresh ethtool commandTaehee Yoo3-2/+10
The bnxt_en driver has configured the hds_threshold value automatically when TPA is enabled based on the rx-copybreak default value. Now the hds-thresh ethtool command is added, so it adds an implementation of hds-thresh option. Configuration of the hds-thresh is applied only when the tcp-data-split is enabled. The default value of hds-thresh is 256, which is the default value of rx-copybreak, which used to be the hds_thresh value. The maximum hds-thresh is 1023. # Example: # ethtool -G enp14s0f0np0 tcp-data-split on hds-thresh 256 # ethtool -g enp14s0f0np0 Ring parameters for enp14s0f0np0: Pre-set maximums: ... HDS thresh: 1023 Current hardware settings: ... TCP data split: on HDS thresh: 256 Tested-by: Stanislav Fomichev <sdf@fomichev.me> Tested-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250114142852.3364986-9-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16bnxt_en: add support for tcp-data-split ethtool commandTaehee Yoo4-3/+28
NICs that uses bnxt_en driver supports tcp-data-split feature by the name of HDS(header-data-split). But there is no implementation for the HDS to enable by ethtool. Only getting the current HDS status is implemented and The HDS is just automatically enabled only when either LRO, HW-GRO, or JUMBO is enabled. The hds_threshold follows rx-copybreak value. and it was unchangeable. This implements `ethtool -G <interface name> tcp-data-split <value>` command option. The value can be <on> and <auto>. The value is <auto> and one of LRO/GRO/JUMBO is enabled, HDS is automatically enabled and all LRO/GRO/JUMBO are disabled, HDS is automatically disabled. HDS feature relies on the aggregation ring. So, if HDS is enabled, the bnxt_en driver initializes the aggregation ring. This is the reason why BNXT_FLAG_AGG_RINGS contains HDS condition. Acked-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Stanislav Fomichev <sdf@fomichev.me> Tested-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250114142852.3364986-8-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16bnxt_en: add support for rx-copybreak ethtool commandTaehee Yoo3-14/+63
The bnxt_en driver supports rx-copybreak, but it couldn't be set by userspace. Only the default value(256) has worked. This patch makes the bnxt_en driver support following command. `ethtool --set-tunable <devname> rx-copybreak <value> ` and `ethtool --get-tunable <devname> rx-copybreak`. By this patch, hds_threshol is set to the rx-copybreak value. But it will be set by `ethtool -G eth0 hds-thresh N` in the next patch. Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Tested-by: Stanislav Fomichev <sdf@fomichev.me> Tested-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250114142852.3364986-7-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: disallow setup single buffer XDP when tcp-data-split is enabled.Taehee Yoo1-0/+15
When a single buffer XDP is attached, NIC should guarantee only single page packets will be received. tcp-data-split feature splits packets into header and payload. single buffer XDP can't handle it properly. So attaching single buffer XDP should be disallowed when tcp-data-split is enabled. Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-6-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: ethtool: add ring parameter filteringTaehee Yoo1-0/+13
While the devmem is running, the tcp-data-split and hds-thresh configuration should not be changed. If user tries to change tcp-data-split and threshold value while the devmem is running, it fails and shows extack message. Reviewed-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-5-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: devmem: add ring parameter filteringTaehee Yoo1-0/+11
If driver doesn't support ring parameter or tcp-data-split configuration is not sufficient, the devmem should not be set up. Before setup the devmem, tcp-data-split should be ON and hds-thresh value should be 0. Tested-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-4-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: ethtool: add support for configuring hds-threshTaehee Yoo6-4/+55
The hds-thresh option configures the threshold value of the header-data-split. If a received packet size is larger than this threshold value, a packet will be split into header and payload. The header indicates TCP and UDP header, but it depends on driver spec. The bnxt_en driver supports HDS(Header-Data-Split) configuration at FW level, affecting TCP and UDP too. So, If hds-thresh is set, it affects UDP and TCP packets. Example: # ethtool -G <interface name> hds-thresh <value> # ethtool -G enp14s0f0np0 tcp-data-split on hds-thresh 256 # ethtool -g enp14s0f0np0 Ring parameters for enp14s0f0np0: Pre-set maximums: ... HDS thresh: 1023 Current hardware settings: ... TCP data split: on HDS thresh: 256 The default/min/max values are not defined in the ethtool so the drivers should define themself. The 0 value means that all TCP/UDP packets' header and payload will be split. Tested-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-3-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: ethtool: add hds_config member in ethtool_netdev_stateTaehee Yoo4-0/+27
When tcp-data-split is UNKNOWN mode, drivers arbitrarily handle it. For example, bnxt_en driver automatically enables if at least one of LRO/GRO/JUMBO is enabled. If tcp-data-split is UNKNOWN and LRO is enabled, a driver returns ENABLES of tcp-data-split, not UNKNOWN. So, `ethtool -g eth0` shows tcp-data-split is enabled. The problem is in the setting situation. In the ethnl_set_rings(), it first calls get_ringparam() to get the current driver's config. At that moment, if driver's tcp-data-split config is UNKNOWN, it returns ENABLE if LRO/GRO/JUMBO is enabled. Then, it sets values from the user and driver's current config to kernel_ethtool_ringparam. Last it calls .set_ringparam(). The driver, especially bnxt_en driver receives ETHTOOL_TCP_DATA_SPLIT_ENABLED. But it can't distinguish whether it is set by the user or just the current config. When user updates ring parameter, the new hds_config value is updated and current hds_config value is stored to old_hdsconfig. Driver's .set_ringparam() callback can distinguish a passed tcp-data-split value is came from user explicitly. If .set_ringparam() is failed, hds_config is rollbacked immediately. Suggested-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-2-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: loopback: Hold rtnl_net_lock() in blackhole_netdev_init().Kuniyuki Iwashima1-3/+2
blackhole_netdev is the global device in init_net. Let's hold rtnl_net_lock(&init_net) in blackhole_netdev_init(). While at it, the unnecessary dev_net_set() call is removed, which is done in alloc_netdev_mqs(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250114081352.47404-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests/net/forwarding: teamd command not foundAlessandro Zanni8-0/+11
Running "make kselftest TARGETS=net/forwarding" results in multiple ccurrences of the same error: - ./lib.sh: line 787: teamd: command not found This patch adds the variable $REQUIRE_TEAMD in every test that uses the command teamd and checks the $REQUIRE_TEAMD variable in the file "lib.sh" to skip the test if the command is not installed. Signed-off-by: Alessandro Zanni <alessandro.zanni87@gmail.com> Link: https://patch.msgid.link/20250114003323.97207-1-alessandro.zanni87@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16Merge branch 'eth-fbnic-add-hardware-monitoring-support'Jakub Kicinski8-0/+357
Sanman Pradhan says: ==================== eth: fbnic: Add hardware monitoring support This patch series adds hardware monitoring support to the fbnic driver. It implements support for reading temperature and voltage sensors via firmware requests, and exposes this data through the HWMON interface. The series is structured as follows: Patch 1: Adds completion infrastructure for firmware requests Patch 2: Implements TSENE sensor message handling Patch 3: Adds HWMON interface support Output: $ ls -l /sys/class/hwmon/hwmon1/ total 0 lrwxrwxrwx 1 root root 0 Sep 10 00:00 device -> ../../../0000:01:00.0 -r--r--r-- 1 root root 4096 Sep 10 00:00 in0_input -r--r--r-- 1 root root 4096 Sep 10 00:00 name lrwxrwxrwx 1 root root 0 Sep 10 00:00 subsystem -> ../../../../../../class/hwmon -r--r--r-- 1 root root 4096 Sep 10 00:00 temp1_input -rw-r--r-- 1 root root 4096 Sep 10 00:00 uevent $ cat /sys/class/hwmon/hwmon1/temp1_input 40480 $ cat /sys/class/hwmon/hwmon1/in0_input 750 ==================== Link: https://patch.msgid.link/20250114000705.2081288-1-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16eth: fbnic: Add hardware monitoring support via HWMON interfaceSanman Pradhan4-0/+89
This patch adds support for hardware monitoring to the fbnic driver, allowing for temperature and voltage sensor data to be exposed to userspace via the HWMON interface. The driver registers a HWMON device and provides callbacks for reading sensor data, enabling system admins to monitor the health and operating conditions of fbnic. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-4-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16eth: fbnic: hwmon: Add support for reading temperature and voltage sensorsSanman Pradhan4-4/+179
Add support for reading temperature and voltage sensor data from firmware by implementing a new TSENE message type and response parsing. This adds message handler infrastructure to transmit sensor read requests and parse responses. The sensor data will be exposed through the driver's hwmon interface. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-3-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16eth: fbnic: hwmon: Add completion infrastructure for firmware requestsSanman Pradhan3-0/+93
Add infrastructure to support firmware request/response handling with completions. Add a completion structure to track message state including message type for matching, completion for waiting for response, and result for error propagation. Use existing spinlock to protect the writes. The data from the various response types will be added to the "union u" by subsequent commits. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-2-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16Merge branch 'net-lan969x-add-fdma-support'Jakub Kicinski9-33/+518
Daniel Machon says: ==================== net: lan969x: add FDMA support == Description: This series is the last of a multi-part series, that prepares and adds support for the new lan969x switch driver. The upstreaming efforts has been split into multiple series: 1) Prepare the Sparx5 driver for lan969x (merged) 2) Add support for lan969x (same basic features as Sparx5 provides excl. FDMA and VCAP, merged). 3) Add lan969x VCAP functionality (merged). 4) Add RGMII support (merged). --> 5) Add FDMA support. == FDMA support: The lan969x switch device uses the same FDMA engine as the Sparx5 switch device, with the same number of channels etc. This means we can utilize the newly added FDMA library, that is already in use by the lan966x and sparx5 drivers. As previous lan969x series, the FDMA implementation will hook into the Sparx5 implementation where possible, however both RX and TX handling will be done differently on lan969x and therefore requires a separate implementation of the RX and TX path. Details are in the commit description of the individual patches == Patch breakdown: Patch #1: Enable FDMA support on lan969x Patch #2: Split start()/stop() functions Patch #3: Activate TX FDMA in start() Patch #4: Ops out a few functions that differ on the two platforms Patch #5: Add FDMA implementation for lan969x v1: https://lore.kernel.org/20250109-sparx5-lan969x-switch-driver-5-v1-0-13d6d8451e63@microchip.com ==================== Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-0-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: lan969x: add FDMA implementationDaniel Machon8-7/+448
The lan969x switch device supports manual frame injection and extraction to and from the switch core, using a number of injection and extraction queues. This technique is currently supported, but delivers poor performance compared to Frame DMA (FDMA). This lan969x implementation of FDMA, hooks into the existing FDMA for Sparx5, but requires its own RX and TX handling, as lan969x does not support the same native cache coherency that Sparx5 does. Effectively, this means that we are going to use the DMA mapping API for mapping and unmapping TX buffers. The RX loop will utilize the page pool API for efficient RX handling. Other than that, the implementation is largely the same, and utilizes the FDMA library for DCB and DB handling. Some numbers: Manual injection/extraction (before this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.02 sec 345 MBytes 289 Mbits/sec sender [ 5] 0.00-10.06 sec 345 MBytes 288 Mbits/sec receiver FDMA (after this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec sender [ 5] 0.00-10.07 sec 1.10 GBytes 936 Mbits/sec receiver Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-5-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: sparx5: ops out certain FDMA functionsDaniel Machon4-7/+24
We are going to implement the RX and TX paths a bit differently on lan969x and therefore need to introduce new ops for FDMA functions: init, deinit, xmit and poll. Assign the Sparx5 equivalents for these and update the code throughout. Also add a 'struct net_device' argument to the xmit() function, as we will be needing that for lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-4-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: sparx5: activate FDMA tx in start()Daniel Machon1-7/+4
The function sparx5_fdma_tx_activate() is responsible for configuring the TX FDMA instance and activating the channel. TX activation has previously been done in the xmit() function, when the first frame is transmitted. Now that we have separate functions for starting and stopping the FDMA, it seems reasonable to move the TX activation to the start function. This change has no implications on the functionality. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-3-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: sparx5: split sparx5_fdma_{start(),stop()}Daniel Machon3-12/+41
The two functions: sparx5_fdma_{start(),stop()} are responsible for a number of things, namely: allocation and initialization of FDMA buffers, activation FDMA channels in hardware and activation of the NAPI instance. This patch splits the buffer allocation and initialization into init and deinit functions, and the channel and NAPI activation into start and stop functions. This serves two purposes: 1) the start() and stop() functions can be reused for lan969x and 2) prepares for future MTU change support, where we must be able to stop and start the FDMA channels and NAPI instance, without free'ing and reallocating the FDMA buffers. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-2-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: sparx5: enable FDMA on lan969xDaniel Machon1-2/+3
In a previous series, we made sure that FDMA was not initialized and started on lan969x. Now that we are going to support it, undo that change. In addition, make sure the chip ID check is only applicable on Sparx5, as this is a check that is only relevant on this platform. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-1-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16Merge branch 'net-phylink-fix-pcs-without-autoneg'Jakub Kicinski22-42/+87
Russell King says: ==================== net: phylink: fix PCS without autoneg Eric Woudstra reported that a PCS attached using 2500base-X does not see link when phylink is using in-band mode, but autoneg is disabled, despite there being a valid 2500base-X signal being received. We have these settings: act_link_an_mode = MLO_AN_INBAND pcs_neg_mode = PHYLINK_PCS_NEG_INBAND_DISABLED Eric diagnosed it to phylink_decode_c37_word() setting state->link false because the full-duplex bit isn't set in the non-existent link partner advertisement word (which doesn't exist because in-band autoneg is disabled!) The test in phylink_mii_c22_pcs_decode_state() is supposed to catch this state, but since we converted PCS to use neg_mode, testing the Autoneg in the local advertisement is no longer sufficient - we need to be looking at the neg_mode, which currently isn't provided. We need to provide this via the .pcs_get_state() method, and this will require modifying all PCS implementations to add the extra argument to this method. Patch 1 uses the PCS neg_mode in phylink_mac_pcs_get_state() to correct the now obsolute usage of the Autoneg bit in the advertisement. Patch 2 passes neg_mode into the .pcs_get_state() method, and updates all users. Patch 3 adds neg_mode as an argument to the various clause 22 state decoder functions in phylink, modifying drivers to pass the neg_mode through. Patch 4 makes use of phylink_mii_c22_pcs_decode_state() rather than using the Autoneg bit in the advertising field. Patch 5 may be required for Eric's case - it ensures that we report the correct state for interface types that we support only one set of modes for when autoneg is disabled. ==================== Link: https://patch.msgid.link/Z4TbR93B-X8A8iHe@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: phylink: provide fixed state for 1000base-X and 2500base-XRussell King (Oracle)1-10/+19
When decoding clause 22 state, if in-band is disabled and using either 1000base-X or 2500base-X, rather than reporting link-down, we know the speed, and we only support full duplex. Pause modes taken from XPCS. This fixes a problem reported by Eric Woudstra. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGei-000EtL-Fn@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: phylink: use neg_mode in phylink_mii_c22_pcs_decode_state()Russell King (Oracle)1-4/+8
Rather than using the state of the Autoneg bit, which is unreliable with the new PCS neg mode support, use the passed neg_mode to decide whether to decode the link partner advertisement data. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGed-000EtF-CN@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: phylink: pass neg_mode into c22 state decoderRussell King (Oracle)10-13/+19
Pass the current neg_mode into phylink_mii_c22_pcs_get_state() and phylink_mii_c22_pcs_decode_state(). Update all users of phylink PCS that use these functions. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeY-000Et9-8g@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: phylink: pass neg_mode into .pcs_get_state() methodRussell King (Oracle)20-15/+31
Pass the current neg_mode into the .pcs_get_state() method. Update all users of phylink PCS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeT-000Et3-4L@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: phylink: use pcs_neg_mode in phylink_mac_pcs_get_state()Russell King (Oracle)1-6/+16
As in-band AN no longer just depends on MLO_AN_INBAND + Autoneg bit, we need to take account of the pcs_neg_mode when deciding how to initialise the speed, duplex and pause state members before calling into the .pcs_neg_mode() method. Add this. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeO-000Esx-0r@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16Merge branch 'mptcp-selftests-more-debug-in-case-of-errors'Jakub Kicinski5-28/+53
Matthieu Baerts says: ==================== mptcp: selftests: more debug in case of errors Here are just a bunch of small improvements for the MPTCP selftests: Patch 1: Unify errors messages in simult_flows: print MIB and 'ss -Me'. Patch 2: Unify errors messages in sockopt: print MIB. Patch 3: Move common code to print debug info to mptcp_lib.sh. Patch 4: Use 'ss' with '-m' in case of errors. Patch 5: Remove an unused variable. Patch 6: Print only the size instead of size + filename again. ==================== Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-0-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: connect: better display the files sizeMatthieu Baerts (NGI0)1-1/+1
'du' will print the name of the file, which was already displayed before, e.g. Created /tmp/tmp.UOyy0ghfmQ (size 4703740/tmp/tmp.UOyy0ghfmQ) containing data sent by client Created /tmp/tmp.xq3zvFinGo (size 1391724/tmp/tmp.xq3zvFinGo) containing data sent by server 'stat' can be used instead, to display this instead: Created /tmp/tmp.UOyy0ghfmQ (size 4703740 B) containing data sent by client Created /tmp/tmp.xq3zvFinGo (size 1391724 B) containing data sent by server So easier to spot the file sizes. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-6-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: connect: remove unused variableMatthieu Baerts (NGI0)1-2/+1
'cin_disconnect' is used in run_tests_disconnect(), but not 'cout_disconnect', so it is safe to drop it. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-5-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: add -m with ss in case of errorsMatthieu Baerts (NGI0)1-2/+2
Recently, we had an issue where getting info about the memory would have helped better understanding what went wrong. Let add it just in case for later. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-4-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: move stats info in case of errors to lib.shMatthieu Baerts (NGI0)5-25/+29
A few MPTCP selftests are using the same code to print stats in case of error. This code can then be moved to mptcp_lib.sh. No behaviour changes intended, except to print the error in red and to stderr, like most error messages. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-3-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: sockopt: save nstat infosGeliang Tang1-1/+12
Similar to the way nstat information is stored in mptcp_connect.sh and mptcp_join.sh scripts, this patch adds a similar way for mptcp_sockopt.sh and displays the nstat information when errors occur. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-2-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16selftests: mptcp: simult_flows: unify errors msgsMatthieu Baerts (NGI0)1-5/+16
In order to unify what is printed in case of error, similar to what is done in mptcp_connect.sh and mptcp_join.sh, it is interesting to do the following modifications in simult_flows.sh: - Print the rc errors at the end of the line. - Print the MIB counters. - Use the same ss options: add -M (MPTCP sockets) and -e (detailed socket information). While at it, also print of the 'max' time only in case of success, because 'mptcp_connect.c' will already print this info in case of error, e.g.: transfer slower than expected! runtime 11948 ms, expected 11921 ms Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-1-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16mptcp: fix for setting remote ipv4mapped addressGeliang Tang1-1/+1
Commit 1c670b39cec7 ("mptcp: change local addr type of subflow_destroy") introduced a bug in mptcp_pm_nl_subflow_destroy_doit(). ipv6_addr_set_v4mapped() should be called to set the remote ipv4 address 'addr_r.addr.s_addr' to the remote ipv6 address 'addr_r.addr6', not 'addr_l.addr.addr6', which is the local ipv6 address. Fixes: 1c670b39cec7 ("mptcp: change local addr type of subflow_destroy") Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-fix-remote-addr-v1-1-debcd84ea86f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16Merge branch 'net-bcm-asp2-fix-fallout-from-phylib-eee-changes'Jakub Kicinski3-50/+14
Russell King says: ==================== net: bcm: asp2: fix fallout from phylib EEE changes This series addresses the fallout from the phylib changes in the Broadcom ASP2 driver. The first patch uses phylib's copy of the LPI timer setting, which means the driver no longer has to track this. It will be set in hardware each time the adjust_link function is called when the link is up, and will be read at initialisation time to set the current value. The second patch removes the driver's storage of tx_lpi_enabled, which has become redundant since phylib managed EEE was merged. The driver does nothing with this flag other than storing it. The last patch converts the driver to use phylib's enable_tx_lpi flag rather than trying to maintain its own copy. ==================== Link: https://patch.msgid.link/Z4aV3RmSZJ1WS3oR@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: bcm: asp2: convert to phylib managed EEERussell King (Oracle)3-43/+10
Convert the Broadcom ASP2 driver to use phylib managed EEE support. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk81-000r4x-TS@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: bcm: asp2: remove tx_lpi_enabledRussell King (Oracle)1-6/+0
Phylib maintains a copy of tx_lpi_enabled, which will be used to populate the member when phy_ethtool_get_eee(). Therefore, writing to this member before phy_ethtool_get_eee() will have no effect. Remove it. Also remove setting our copy of info->eee.tx_lpi_enabled which becomes write-only. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk7w-000r4r-Pq@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-16net: bcm: asp2: fix LPI timer handlingRussell King (Oracle)2-2/+5
Fix the LPI timer handling in Broadcom ASP2 driver after the phylib managed EEE patches were merged. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk7r-000r4l-Li@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15Merge branch 'net-stmmac-further-eee-cleanups-and-one-fix'Jakub Kicinski1-25/+33
Russell King says: ==================== net: stmmac: further EEE cleanups (and one fix!) This series continues the EEE cleanup of the stmmac driver, and includes one fix. As mentioned in the previous series, I wasn't entirely happy with the "stmmac_disable_sw_eee_mode" name, so the first patch renames this to "stmmac_stop_sw_lpi" instead, which I think better describes what this function is doing - stopping the transmit of the LPI state because we have a packet ot send. Patch 2 corrects the priv->eee_sw_timer_en flag when EEE has been disabled. Currently upon disable, priv->eee_enabled is set false, but through the weird logic that was present prior to the previous series, priv->eee_sw_timer_en was set true. This behaviour was kept as the previous series was cleanup, not fixes. This patch fixes this. Having fixed priv->eee_sw_timer_en to actually indicate whether software timed EEE mode is being used, it becomes no longer necessary to test priv->eee_enabled in addition. Patch 3 removes the redundant test. Patch 4 also uses priv->eee_sw_timer_en before manipulating the software EEE state in the suspend method rather than using priv->eee_enabled, which brings consistency. Patch 5 provides stmmac_try_to_start_sw_lpi() which complements stmmac_stop_sw_lpi(), and allows us to move duplicated code into one location. Patch 6 splits stmmac_enable_eee_mode() - one part of this function tests whether there are any queues that have unfinished work (in other words are busy). Separate out this code into a separate function. Patch 7 also splits out the mod_timer() for the software EEE timer intoi a seperate function (the reason will be in patch 9.) Patch 8 merges the remains of stmmac_enable_eee_mode() into stmmac_try_to_start_sw_lpi(). Patch 9 fixes the delay between transmit and entering LPI. Currently, when cleaning the transmit queues, if we discover that we have finished cleaning up all queues, we immediately instruct the hardware to enter LPI mode without waiting for the LPI timer. However, we should wait for the LPI timer to expire. Therefore, the transmit cleanup path needs to call stmmac_restart_sw_lpi_timer() instead of stmmac_try_to_start_sw_lpi(). ==================== Link: https://patch.msgid.link/Z4T84SbaC4D-fN5y@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: restart LPI timer after cleaning transmit descriptorsRussell King (Oracle)1-1/+1
Fix a bug in the LPI handling, where it is possible to immediately enter LPI mode after cleaning the transmit descriptors when all queues are empty rather than waiting for the LPI timeout to expire. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItg-000MBg-TW@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: combine stmmac_enable_eee_mode()Russell King (Oracle)1-11/+6
Combine stmmac_enable_eee_mode() with stmmac_try_to_start_sw_lpi() which makes the code easier to read and the flow more logical. We can now trivially see that if the transmit queues are busy, we (re-)start the eee_ctrl_timer. Otherwise, if the transmit path is not already in LPI mode, we ask the hardware to enter LPI mode. I believe that now we can see better what is going on here, this shows that there is a bug with the software LPI timer implementation. The LPI timer is supposed to define how long after the last transmittion completed before we start signalling LPI. However, this code structure shows that if all transmit queues are empty, and stmmac_try_to_start_sw_lpi() is called immediately after cleaning the transmit queue, we will instruct the hardware to start signalling LPI immediately. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItb-000MBa-OU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: provide function for restarting sw LPI timerRussell King (Oracle)1-4/+7
Provide a function that encapsulates restarting the software LPI timer when we have determined that the transmit path is busy, or whether the EEE parameters have changed. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItW-000MBU-KQ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: provide stmmac_eee_tx_busy()Russell King (Oracle)1-8/+16
Extract the code which checks whether there's still work to do on any of the stmmac transmit queues. This will allow us to combine stmmac_enable_eee_mode() with stmmac_try_to_start_sw_lpi() in the next patch. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItR-000MBO-GF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: add stmmac_try_to_start_sw_lpi()Russell King (Oracle)1-6/+10
There are two places which call stmmac_enable_eee_mode() and follow it immediately by modifying the expiry of priv->eee_ctrl_timer. Both code paths are trying to enable LPI mode. Remove this duplication by providing a function for this. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItM-000MBI-CX@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: check priv->eee_sw_timer_en in suspend pathRussell King (Oracle)1-1/+1
The suspend path uses priv->eee_enabled when cleaning up the software timed LPI mode. Use priv->eee_sw_timer_en instead so we're consistently using a single control for software-based timer handling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItH-000MBC-8i@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: simplify TX cleanup decision for ending sw LPI modeRussell King (Oracle)1-2/+1
As mentioned in "net: stmmac: correct priv->eee_sw_timer_en setting", we can simplify some fast-path tests. The transmit cleaning path checks whether EEE is enabled, the transmit path is not in LPI mode, and that we're using software timed mode. Since the above mentioned commit, checking whether EEE is enabled is no longer necessary as priv->eee_sw_timer_en will be false when EEE is disabled. Simplify this test. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXItC-000MB6-54@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: correct priv->eee_sw_timer_en settingRussell King (Oracle)1-1/+1
If we are disabling EEE/LPI, then we should not be enabling software mode. The only time when we should is if EEE is active, and we are wanting to use software-timed EEE mode. Therefore, in the disable path of stmmac_eee_init(), ensure that priv->eee_sw_timer_en is set false as we are going to be calling del_timer_sync() on the timer. This will allow us to simplify some fast-path tests in later patches. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXIt7-000MB0-0W@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: stmmac: rename stmmac_disable_sw_eee_mode()Russell King (Oracle)1-5/+4
stmmac_disable_sw_eee_mode() was not a good choice for this functions purpose - which is to stop transmitting LPI because we want to send a packet. Rename it to stmmac_stop_sw_lpi(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tXIt1-000MAu-TE@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: ethernet: sunplus: Switch to ndo_eth_ioctl谢致邦 (XIE Zhibang)1-1/+1
The device ioctl handler no longer calls ndo_do_ioctl, but calls ndo_eth_ioctl to handle mii ioctls since commit a76053707dbf ("dev_ioctl: split out ndo_eth_ioctl"). However, sunplus still used ndo_do_ioctl when it was introduced. So switch to ndo_eth_ioctl. Bad commit fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021") was the initial driver commit, meaning that PHY IOCTLs where never available on this driver. Therefore don't consider this as a fix. Found by code inspection. Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com> Link: https://patch.msgid.link/tencent_8CF8A72C708E96B9C7DC1AF96FEE19AF3D05@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-11 16:55:46 +0300