Changes in Makefile

6e9e2eed - net: ethtool: Add support for tsconfig command to get/set hwtstamp config

Thu, 12 Dec 2024 17:06:45 +0000

net: ethtool: Add support for tsconfig command to get/set hwtstamp configIntroduce support for ETHTOOL_MSG_TSCONFIG_GET/SET ethtool netlink socketto read and configure hwtstamp configuration of a PHC provider. Note thatsimultaneous hwtstamp isn't supported; configuring a new one disables theprevious setting.Signed-off-by: Kory Maincent Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

17194be4 - net: ethtool: Introduce a command to list PHYs on an interface

Wed, 21 Aug 2024 15:10:01 +0000

net: ethtool: Introduce a command to list PHYs on an interfaceAs we have the ability to track the PHYs connected to a net_devicethrough the link_topology, we can expose this list to userspace. Thisallows userspace to use these identifiers for phy-specific commands andtake the decision of which PHY to target by knowing the link topology.Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to listdevices on only one interface.Signed-off-by: Maxime Chevallier Reviewed-by: Christophe Leroy Tested-by: Christophe Leroy Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

c4f78134 - ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB

Thu, 27 Jun 2024 14:08:55 +0000

ethtool: cmis_fw_update: add a layer for supporting firmware update using CDBAccording to the CMIS standard, the firmware update process is done usinga CDB commands sequence.Implement a work that will be triggered from the module layer in thenext patch the will initiate and execute all the CDB commands in order, toeventually complete the firmware update process.This flashing process includes, writing the firmware image, running the newfirmware image and committing it after testing, so that it will run uponreset.This work will also notify user space about the progress of the firmwareupdate process.Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

a39c84d7 - ethtool: cmis_cdb: Add a layer for supporting CDB commands

Thu, 27 Jun 2024 14:08:54 +0000

ethtool: cmis_cdb: Add a layer for supporting CDB commandsCDB (Command Data Block Message Communication) reads and writes areperformed on memory map pages 9Fh-AFh according to the CMIS standard,section 8.20 of revision 5.2.Page 9Fh is used to specify the CDB command to be executed and alsoprovides an area for a local payload (LPL).According to the CMIS standard, the firmware update process is done usinga CDB commands sequence that will be implemented in the next patch.The kernel interface that will implement the firmware update using CDBcommand will include 2 layers that will be added under ethtool:* The upper layer that will be triggered from the module layer, is cmis_fw_update.* The lower one is cmis_cdb.In the future there might be more operations to implement using CDBcommands. Therefore, the idea is to keep the CDB interface clean and thecmis_fw_update specific to the CDB commands handling it.These two layers will communicate using the API the consists of threefunctions:- struct ethtool_cmis_cdb * ethtool_cmis_cdb_init(struct net_device *dev, struct ethtool_module_fw_flash_params *params);- void ethtool_cmis_cdb_fini(struct ethtool_cmis_cdb *cdb);- int ethtool_cmis_cdb_execute_cmd(struct net_device *dev, struct ethtool_cmis_cdb_cmd_args *args);Add the CDB layer to support initializing, finishing and executing CDBcommands:* The initialization process will include creating of an ethtool_cmis_cdb instance, querying the module CDB support, entering and validating the password from user space (CMD 0x0000) and querying the module features (CMD 0x0040).* The finishing API will simply free the ethtool_cmis_cdb instance.* The executing process will write the CDB command to EEPROM using set_module_eeprom_by_page() that was presented earlier, and will process the reply from EEPROM.Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

fe1eb24b - Revert "Introduce PHY listing and link_topology tracking"

Fri, 05 Jan 2024 00:04:35 +0000

Revert "Introduce PHY listing and link_topology tracking"This reverts commit 32bb4515e34469975abc936deb0a116c4a445817.This reverts commit d078d480639a4f3b5fc2d56247afa38e0956483a.This reverts commit fcc4b105caa4b844bf043375bf799c20a9c99db1.This reverts commit 345237dbc1bdbb274c9fb9ec38976261ff4a40b8.This reverts commit 7db69ec9cfb8b4ab50420262631fb2d1908b25bf.This reverts commit 95132a018f00f5dad38bdcfd4180d1af955d46f6.This reverts commit 63d5eaf35ac36cad00cfb3809d794ef0078c822b.This reverts commit c29451aefcb42359905d18678de38e52eccb3bb5.This reverts commit 2ab0edb505faa9ac90dee1732571390f074e8113.This reverts commit dedd702a35793ab462fce4c737eeba0badf9718e.This reverts commit 034fcc210349b873ece7356905be5c6ca11eef2a.This reverts commit 9c5625f559ad6fe9f6f733c11475bf470e637d34.This reverts commit 02018c544ef113e980a2349eba89003d6f399d22.Looks like we need more time for reviews, and incrementalchanges will be hard to make sense of. So revert.Link: https://lore.kernel.org/all/ZZP6FV5sXEf+xd58@shell.armlinux.org.uk/Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

63d5eaf3 - net: ethtool: Introduce a command to list PHYs on an interface

Thu, 21 Dec 2023 18:00:40 +0000

net: ethtool: Introduce a command to list PHYs on an interfaceAs we have the ability to track the PHYs connected to a net_devicethrough the link_topology, we can expose this list to userspace. Thisallows userspace to use these identifiers for phy-specific commands andtake the decision of which PHY to target by knowing the link topology.Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to listdevices on only one interface.Signed-off-by: Maxime Chevallier Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

289354f2 - net: partial revert of the "Make timestamping selectable: series

Sun, 19 Nov 2023 02:38:05 +0000

net: partial revert of the "Make timestamping selectable: seriesRevert following commits:commit acec05fb78ab ("net_tstamp: Add TIMESTAMPING SOFTWARE and HARDWARE mask")commit 11d55be06df0 ("net: ethtool: Add a command to expose current time stamping layer")commit bb8645b00ced ("netlink: specs: Introduce new netlink command to get current timestamp")commit d905f9c75329 ("net: ethtool: Add a command to list available time stamping layers")commit aed5004ee7a0 ("netlink: specs: Introduce new netlink command to list available time stamping layers")commit 51bdf3165f01 ("net: Replace hwtstamp_source by timestamping layer")commit 0f7f463d4821 ("net: Change the API of PHY default timestamp to MAC")commit 091fab122869 ("net: ethtool: ts: Update GET_TS to reply the current selected timestamp")commit 152c75e1d002 ("net: ethtool: ts: Let the active time stamping layer be selectable")commit ee60ea6be0d3 ("netlink: specs: Introduce time stamping set command")They need more time for reviews.Link: https://lore.kernel.org/all/20231118183529.6e67100c@kernel.org/Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

11d55be0 - net: ethtool: Add a command to expose current time stamping layer

Tue, 14 Nov 2023 11:28:36 +0000

net: ethtool: Add a command to expose current time stamping layerTime stamping on network packets may happen either in the MAC or inthe PHY, but not both. In preparation for making the choiceselectable, expose both the current layers via ethtool.In accordance with the kernel implementation as it stands, the currentlayer will always read as "phy" when a PHY time stamping device ispresent. Future patches will allow changing the current layeradministratively.Signed-off-by: Kory Maincent Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

2b30f829 - net: ethtool: add support for MAC Merge layer

Thu, 19 Jan 2023 12:26:54 +0000

net: ethtool: add support for MAC Merge layerThe MAC merge sublayer (IEEE 802.3-2018 clause 99) is one of 2specifications (the other being Frame Preemption; IEEE 802.1Q-2018clause 6.7.2), which work together to minimize latency caused by frameinterference at TX. The overall goal of TSN is for normal traffic andtraffic with a bounded deadline to be able to cohabitate on the same L2network and not bother each other too much.The standards achieve this (partly) by introducing the concept ofpreemptible traffic, i.e. Ethernet frames that have a custom value forthe Start-of-Frame-Delimiter (SFD), and these frames can be fragmentedand reassembled at L2 on a link-local basis. The non-preemptible framesare called express traffic, they are transmitted using a normal SFD, andthey can preempt preemptible frames, therefore having lower latency,which can matter at lower (100 Mbps) link speeds, or at high MTUs (jumboframes around 9K). Preemption is not recursive, i.e. a P frame cannotpreempt another P frame. Preemption also does not depend upon priority,or otherwise said, an E frame with prio 0 will still preempt a P framewith prio 7.In terms of implementation, the standards talk about the presence of anexpress MAC (eMAC) which handles express traffic, and a preemptible MAC(pMAC) which handles preemptible traffic, and these MACs are multiplexedon the same MII by a MAC merge layer.To support frame preemption, the definition of the SFD was generalizedto SMD (Start-of-mPacket-Delimiter), where an mPacket is essentially anEthernet frame fragment, or a complete frame. Stations unaware of an SMDvalue different from the standard SFD will treat P frames as errorframes. To prevent that from happening, a negotiation process isdefined.On RX, packets are dispatched to the eMAC or pMAC after being filteredby their SMD. On TX, the eMAC/pMAC classification decision is taken bythe 802.1Q spec, based on packet priority (each of the 8 user priorityvalues may have an admin-status of preemptible or express).The MAC Merge layer and the Frame Preemption parameters have some degreeof independence in terms of how software stacks are supposed to dealwith them. The activation of the MM layer is supposed to be controlledby an LLDP daemon (after it has been communicated that the link partneralso supports it), after which a (hardware-based or not) verificationhandshake takes place, before actually enabling the feature. So theprocess is intended to be relatively plug-and-play. Whereas FP settingsare supposed to be coordinated across a network using somethingapproximating NETCONF.The support contained here is exclusively for the 802.3 (MAC Merge)portions and not for the 802.1Q (Frame Preemption) parts. This API issufficient for an LLDP daemon to do its job. The FP adminStatus variablefrom 802.1Q is outside the scope of an LLDP daemon.I have taken a few creative licenses and augmented the Linux kernel UAPIcompared to the standard managed objects recommended by IEEE 802.3.These are:- ETHTOOL_A_MM_PMAC_ENABLED: According to Figure 99-6: Receive Processing state diagram, a MAC Merge layer is always supposed to be able to receive P frames. However, this implies keeping the pMAC powered on, which will consume needless power in applications where FP will never be used. If LLDP is used, the reception of an Additional Ethernet Capabilities TLV from the link partner is sufficient indication that the pMAC should be enabled. So my proposal is that in Linux, we keep the pMAC turned off by default and that user space turns it on when needed.- ETHTOOL_A_MM_VERIFY_ENABLED: The IEEE managed object is called aMACMergeVerifyDisableTx. I opted for consistency (positive logic) in the boolean netlink attributes offered, so this is also positive here. Other than the meaning being reversed, they correspond to the same thing.- ETHTOOL_A_MM_MAX_VERIFY_TIME: I found it most reasonable for a LLDP daemon to maximize the verifyTime variable (delay between SMD-V transmissions), to maximize its chances that the LP replies. IEEE says that the verifyTime can range between 1 and 128 ms, but the NXP ENETC stupidly keeps this variable in a 7 bit register, so the maximum supported value is 127 ms. I could have chosen to hardcode this in the LLDP daemon to a lower value, but why not let the kernel expose its supported range directly.- ETHTOOL_A_MM_TX_MIN_FRAG_SIZE: the standard managed object is called aMACMergeAddFragSize, and expresses the "additional" fragment size (on top of ETH_ZLEN), whereas this expresses the absolute value of the fragment size.- ETHTOOL_A_MM_RX_MIN_FRAG_SIZE: there doesn't appear to exist a managed object mandated by the standard, but user space clearly needs to know what is the minimum supported fragment size of our local receiver, since LLDP must advertise a value no lower than that.Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

8580e16c - net/ethtool: add netlink interface for the PLCA RS

Mon, 09 Jan 2023 16:59:39 +0000

net/ethtool: add netlink interface for the PLCA RSAdd support for configuring the PLCA Reconciliation Sublayer onmulti-drop PHYs that support IEEE802.3cg-2019 Clause 148 (e.g.,10BASE-T1S). This patch adds the appropriate netlink interfaceto ethtool.Signed-off-by: Piergiorgio Beruto Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

7112a046 - ethtool: add netlink based get rss support

Fri, 02 Dec 2022 00:25:55 +0000

ethtool: add netlink based get rss supportAdd netlink based support for "ethtool -x [context x]"command by implementing ETHTOOL_MSG_RSS_GET netlink message.This is equivalent to functionality provided via ETHTOOL_GRSSHin ioctl path. It sends RSS table, hash key and hash functionof an interface to user space.This patch implements existing functionality availablein ioctl path and enables addition of new RSS contextbased parameters in future.Signed-off-by: Sudheer Mogilappagari Link: https://lore.kernel.org/r/20221202002555.241580-1-sudheer.mogilappagari@intel.comSigned-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

18ff0bcd - ethtool: add interface to interact with Ethernet Power Equipment

Mon, 03 Oct 2022 06:52:00 +0000

ethtool: add interface to interact with Ethernet Power EquipmentAdd interface to support Power Sourcing Equipment. At current step itprovides generic way to address all variants of PSE devices as definedin IEEE 802.3-2018 but support only objects specified for IEEE 802.3-2018 104.4PoDL Power Sourcing Equipment (PSE).Currently supported and mandatory objects are:IEEE 802.3-2018 30.15.1.1.3 aPoDLPSEPowerDetectionStatusIEEE 802.3-2018 30.15.1.1.2 aPoDLPSEAdminStateIEEE 802.3-2018 30.15.1.2.1 acPoDLPSEAdminControlThis is minimal interface needed to control PSE on each separateethernet port but it provides not all mandatory objects specified inIEEE 802.3-2018.Since "PoDL PSE" and "PSE" have similar names, but some different valuesI decide to not merge them and keep separate naming schema. This shouldallow as to be as close to IEEE 802.3 spec as possible and avoid nameconflicts in the future.This implementation is connected to PHYs instead of MACs because PSEauto classification can potentially interfere with PHY auto negotiation.So, may be some extra PHY related initialization will be needed.With WIP version of ethtools interaction with PSE capable link looksas following:$ ip l...5: t1l1@eth0: .....$ ethtool --show-pse t1l1PSE attributs for t1l1:PoDL PSE Admin State: disabledPoDL PSE Power Detection Status: disabled$ ethtool --set-pse t1l1 podl-pse-admin-control enable$ ethtool --show-pse t1l1PSE attributs for t1l1:PoDL PSE Admin State: enabledPoDL PSE Power Detection Status: delivering powerSigned-off-by: kernel test robot Signed-off-by: Oleksij Rempel Reviewed-by: Bagas Sanjaya Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

353407d9 - ethtool: Add ability to control transceiver modules' power mode

Wed, 06 Oct 2021 10:46:42 +0000

ethtool: Add ability to control transceiver modules' power modeAdd a pair of new ethtool messages, 'ETHTOOL_MSG_MODULE_SET' and'ETHTOOL_MSG_MODULE_GET', that can be used to control transceivermodules parameters and retrieve their status.The first parameter to control is the power mode of the module. It isonly relevant for paged memory modules, as flat memory modules alwaysoperate in low power mode.When a paged memory module is in low power mode, its power consumptionis reduced to the minimum, the management interface towards the host isavailable and the data path is deactivated.User space can choose to put modules that are not currently in use inlow power mode and transition them to high power mode before putting theassociated ports administratively up. This is useful for user space thatfavors reduced power consumption and lower temperatures over reducedlink up times. In QSFP-DD modules the transition from low power mode tohigh power mode can take a few seconds and this transition is onlyexpected to get longer with future / more complex modules.User space can control the power mode of the module via the power modepolicy attribute ('ETHTOOL_A_MODULE_POWER_MODE_POLICY'). Possiblevalues:* high: Module is always in high power mode.* auto: Module is transitioned by the host to high power mode when the first port using it is put administratively up and to low power mode when the last port using it is put administratively down.The operational power mode of the module is available to user space viathe 'ETHTOOL_A_MODULE_POWER_MODE' attribute. The attribute is notreported to user space when a module is not plugged-in.The user API is designed to be generic enough so that it could be usedfor modules with different memory maps (e.g., SFF-8636, CMIS).The only implementation of the device driver API in this series is for aMAC driver (mlxsw) where the module is controlled by the device'sfirmware, but it is designed to be generic enough so that it could alsobe used by implementations where the module is controlled by the CPU.CMIS testing============ # ethtool -m swp11 Identifier : 0x18 (QSFP-DD Double Density 8X Pluggable Transceiver (INF-8628)) ... Module State : 0x03 (ModuleReady) LowPwrAllowRequestHW : Off LowPwrRequestSW : OffThe module is not in low power mode, as it is not forced by hardware(LowPwrAllowRequestHW is off) or by software (LowPwrRequestSW is off).The power mode can be queried from the kernel. In caseLowPwrAllowRequestHW was on, the kernel would need to take into accountthe state of the LowPwrRequestHW signal, which is not visible to userspace. $ ethtool --show-module swp11 Module parameters for swp11: power-mode-policy high power-mode highChange the power mode policy to 'auto': # ethtool --set-module swp11 power-mode-policy autoQuery the power mode again: $ ethtool --show-module swp11 Module parameters for swp11: power-mode-policy auto power-mode lowVerify with the data read from the EEPROM: # ethtool -m swp11 Identifier : 0x18 (QSFP-DD Double Density 8X Pluggable Transceiver (INF-8628)) ... Module State : 0x01 (ModuleLowPwr) LowPwrAllowRequestHW : Off LowPwrRequestSW : OnPut the associated port administratively up which will instruct the hostto transition the module to high power mode: # ip link set dev swp11 upQuery the power mode again: $ ethtool --show-module swp11 Module parameters for swp11: power-mode-policy auto power-mode highVerify with the data read from the EEPROM: # ethtool -m swp11 Identifier : 0x18 (QSFP-DD Double Density 8X Pluggable Transceiver (INF-8628)) ... Module State : 0x03 (ModuleReady) LowPwrAllowRequestHW : Off LowPwrRequestSW : OffPut the associated port administratively down which will instruct thehost to transition the module to low power mode: # ip link set dev swp11 downQuery the power mode again: $ ethtool --show-module swp11 Module parameters for swp11: power-mode-policy auto power-mode lowVerify with the data read from the EEPROM: # ethtool -m swp11 Identifier : 0x18 (QSFP-DD Double Density 8X Pluggable Transceiver (INF-8628)) ... Module State : 0x01 (ModuleLowPwr) LowPwrAllowRequestHW : Off LowPwrRequestSW : OnSFF-8636 testing================ # ethtool -m swp13 Identifier : 0x11 (QSFP28) ... Extended identifier description : 5.0W max. Power consumption, High Power Class (> 3.5 W) enabled Power set : Off Power override : On ... Transmit avg optical power (Channel 1) : 0.7733 mW / -1.12 dBm Transmit avg optical power (Channel 2) : 0.7649 mW / -1.16 dBm Transmit avg optical power (Channel 3) : 0.7790 mW / -1.08 dBm Transmit avg optical power (Channel 4) : 0.7837 mW / -1.06 dBm Rcvr signal avg optical power(Channel 1) : 0.9302 mW / -0.31 dBm Rcvr signal avg optical power(Channel 2) : 0.9079 mW / -0.42 dBm Rcvr signal avg optical power(Channel 3) : 0.8993 mW / -0.46 dBm Rcvr signal avg optical power(Channel 4) : 0.8778 mW / -0.57 dBmThe module is not in low power mode, as it is not forced by hardware(Power override is on) or by software (Power set is off).The power mode can be queried from the kernel. In case Power overridewas off, the kernel would need to take into account the state of theLPMode signal, which is not visible to user space. $ ethtool --show-module swp13 Module parameters for swp13: power-mode-policy high power-mode highChange the power mode policy to 'auto': # ethtool --set-module swp13 power-mode-policy autoQuery the power mode again: $ ethtool --show-module swp13 Module parameters for swp13: power-mode-policy auto power-mode lowVerify with the data read from the EEPROM: # ethtool -m swp13 Identifier : 0x11 (QSFP28) Extended identifier description : 5.0W max. Power consumption, High Power Class (> 3.5 W) not enabled Power set : On Power override : On ... Transmit avg optical power (Channel 1) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 2) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 3) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 4) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 1) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 2) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 3) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 4) : 0.0000 mW / -inf dBmPut the associated port administratively up which will instruct the hostto transition the module to high power mode: # ip link set dev swp13 upQuery the power mode again: $ ethtool --show-module swp13 Module parameters for swp13: power-mode-policy auto power-mode highVerify with the data read from the EEPROM: # ethtool -m swp13 Identifier : 0x11 (QSFP28) ... Extended identifier description : 5.0W max. Power consumption, High Power Class (> 3.5 W) enabled Power set : Off Power override : On ... Transmit avg optical power (Channel 1) : 0.7934 mW / -1.01 dBm Transmit avg optical power (Channel 2) : 0.7859 mW / -1.05 dBm Transmit avg optical power (Channel 3) : 0.7885 mW / -1.03 dBm Transmit avg optical power (Channel 4) : 0.7985 mW / -0.98 dBm Rcvr signal avg optical power(Channel 1) : 0.9325 mW / -0.30 dBm Rcvr signal avg optical power(Channel 2) : 0.9034 mW / -0.44 dBm Rcvr signal avg optical power(Channel 3) : 0.9086 mW / -0.42 dBm Rcvr signal avg optical power(Channel 4) : 0.8885 mW / -0.51 dBmPut the associated port administratively down which will instruct thehost to transition the module to low power mode: # ip link set dev swp13 downQuery the power mode again: $ ethtool --show-module swp13 Module parameters for swp13: power-mode-policy auto power-mode lowVerify with the data read from the EEPROM: # ethtool -m swp13 Identifier : 0x11 (QSFP28) ... Extended identifier description : 5.0W max. Power consumption, High Power Class (> 3.5 W) not enabled Power set : On Power override : On ... Transmit avg optical power (Channel 1) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 2) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 3) : 0.0000 mW / -inf dBm Transmit avg optical power (Channel 4) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 1) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 2) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 3) : 0.0000 mW / -inf dBm Rcvr signal avg optical power(Channel 4) : 0.0000 mW / -inf dBmSigned-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

c156174a - ethtool: add a new command for getting PHC virtual clocks

Wed, 30 Jun 2021 08:11:56 +0000

ethtool: add a new command for getting PHC virtual clocksAdd an interface for getting PHC (PTP Hardware Clock)virtual clocks, which are based on PHC physical clockproviding hardware timestamp to network packets.Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

f09ea6fb - ethtool: add a new command for reading standard stats

Fri, 16 Apr 2021 19:27:39 +0000

ethtool: add a new command for reading standard statsAdd an interface for reading standard stats, includingstats which don't have a corresponding control interface.Start with IEEE 802.3 PHY stats. There seems to be onlyone stat to expose there.Define API to not require user space changes when newstats or groups are added. Groups are based on bitset,stats have a string set associated.v1: wrap stats in a nestSigned-off-by: Jakub Kicinski Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

c781ff12 - ethtool: Allow network drivers to dump arbitrary EEPROM data

Fri, 09 Apr 2021 08:06:34 +0000

ethtool: Allow network drivers to dump arbitrary EEPROM dataDefine get_module_eeprom_by_page() ethtool callback and implementnetlink infrastructure.get_module_eeprom_by_page() allows network drivers to dump a part ofmodule's EEPROM specified by page and bank numbers along with offset andlength. It is effectively a netlink replacement for get_module_info()and get_module_eeprom() pair, which is needed due to emergence ofcomplex non-linear EEPROM layouts.Signed-off-by: Vladyslav Tarasiuk Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

1e5d1f69 - ethtool: support FEC settings over netlink

Tue, 30 Mar 2021 03:59:52 +0000

ethtool: support FEC settings over netlinkAdd FEC API to netlink.This is not a 1-to-1 conversion.FEC settings already depend on link modes to tell user whichmodes are supported. Take this further an use link modes formanual configuration. Old struct ethtool_fecparam is stillused to talk to the drivers, so we need to translate backand forth. We can revisit the internal API if number of FECencodings starts to grow.Enforce only one active FEC bit (by using a bit positionrather than another mask).Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

c7d759eb - ethtool: add tunnel info interface

Fri, 10 Jul 2020 00:42:47 +0000

ethtool: add tunnel info interfaceAdd an interface to report offloaded UDP ports via ethtool netlink.Now that core takes care of tracking which UDP tunnel ports the NICsare aware of we can quite easily export this information out touser space.The responsibility of writing the netlink dumps is split betweenethtool code and udp_tunnel_nic.c - since udp_tunnel module maynot always be loaded, yet we should always report the capabilitiesof the NIC.$ ethtool --show-tunnels eth0Tunnel information for eth0: UDP port table 0: Size: 4 Types: vxlan No entries UDP port table 1: Size: 4 Types: geneve, vxlan-gpe Entries (1): port 1230, vxlan-gpev4: - back to v2, build fix is now directly in udp_tunnel.hv3: - don't compile ETHTOOL_MSG_TUNNEL_INFO_GET in if CONFIG_INET not set.v2: - fix string set count, - reorder enums in the uAPI, - fix type of ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES to bitset in docs and comments.Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile

11ca3c42 - net: ethtool: netlink: Add support for triggering a cable test

Sun, 10 May 2020 19:12:33 +0000

net: ethtool: netlink: Add support for triggering a cable testAdd new ethtool netlink calls to trigger the starting of a PHY cabletest.Add Kconfig'ury to ETHTOOL_NETLINK so that PHYLIB is not a module whenETHTOOL_NETLINK is builtin, which would result in kernel linking errors.v2:Remove unwanted white space changeRemove ethnl_cable_test_act_ops and use doit handlerRename cable_test_set_policy cable_test_act_policyRemove ETHTOOL_MSG_CABLE_TEST_ACT_REPLYv3:Remove ETHTOOL_MSG_CABLE_TEST_ACT_REPLY from documentationRemove unused cable_test_get_policyAdd Reviewed-by tagsv4:Remove unwanted blank lineSigned-off-by: Andrew Lunn Reviewed-by: Michal Kubecek Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/ethtool/Makefile

5b071c59 - ethtool: provide timestamping information with TSINFO_GET request

Fri, 27 Mar 2020 23:01:58 +0000

ethtool: provide timestamping information with TSINFO_GET requestImplement TSINFO_GET request to get timestamping information for a networkdevice. This is traditionally available via ETHTOOL_GET_TS_INFO ioctlrequest.Move part of ethtool_get_ts_info() into common.c so that ioctl and netlinkcode use the same logic to get timestamping information from the device.v3: use "TSINFO" rather than "TIMESTAMP", suggested by Richard CochranSigned-off-by: Michal Kubecek Acked-by: Richard Cochran Signed-off-by: David S. Miller List of files: /linux-6.15/net/ethtool/Makefile