Commit Graph

8 Commits

Author SHA1 Message Date
Michal Schmidt aed91afe41 net: ethtool: Monotonically increase the message sequence number
JIRA: https://issues.redhat.com/browse/RHEL-57750

commit 275a63c9fe10f39066782d2d775d7d3efb20b01f
Author: Danielle Ratson <danieller@nvidia.com>
Date:   Thu Jul 11 11:09:34 2024 +0300

    net: ethtool: Monotonically increase the message sequence number

    Currently, during the module firmware flashing process, unicast
    notifications are sent from the kernel using the same sequence number,
    making it impossible for user space to track missed notifications.

    Monotonically increase the message sequence number, so the order of
    notifications could be tracked effectively.

    Signed-off-by: Danielle Ratson <danieller@nvidia.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Link: https://patch.msgid.link/20240711080934.2071869-1-danieller@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
2024-10-01 12:19:15 +02:00
Michal Schmidt 86f0a122f7 ethtool: move firmware flashing flag to struct ethtool_netdev_state
JIRA: https://issues.redhat.com/browse/RHEL-57750

commit caa93b7c25945d302689de07bd404655db93ae6e
Author: Edward Cree <ecree.xilinx@gmail.com>
Date:   Wed Jul 3 13:18:49 2024 +0100

    ethtool: move firmware flashing flag to struct ethtool_netdev_state

    Commit 31e0aa99dc02 ("ethtool: Veto some operations during firmware flashing process")
     added a flag module_fw_flash_in_progress to struct net_device.  As
     this is ethtool related state, move it to the recently created
     struct ethtool_netdev_state, accessed via the 'ethtool' member of
     struct net_device.

    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://patch.msgid.link/20240703121849.652893-1-edward.cree@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
2024-10-01 12:19:14 +02:00
Michal Schmidt 6283b90ec7 ethtool: Add ability to flash transceiver modules' firmware
JIRA: https://issues.redhat.com/browse/RHEL-57750

commit 32b4c8b53ee7799e34a2b1634d32d3ce1e36c44e
Author: Danielle Ratson <danieller@nvidia.com>
Date:   Thu Jun 27 17:08:56 2024 +0300

    ethtool: Add ability to flash transceiver modules' firmware

    Add the ability to flash the modules' firmware by implementing the
    interface between the user space and the kernel.

    Example from a succeeding implementation:

     # ethtool --flash-module-firmware swp40 file test.bin

     Transceiver module firmware flashing started for device swp40
     Transceiver module firmware flashing in progress for device swp40
     Progress: 99%
     Transceiver module firmware flashing completed for device swp40

    In addition, add infrastructure that allows modules to set socket-specific
    private data. This ensures that when a socket is closed from user space
    during the flashing process, the right socket halts sending notifications
    to user space until the work item is completed.

    Signed-off-by: Danielle Ratson <danieller@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
2024-10-01 12:19:13 +02:00
Michal Schmidt ce404ea41f ethtool: Add flashing transceiver modules' firmware notifications ability
JIRA: https://issues.redhat.com/browse/RHEL-57750

commit d7d4cfc4c97c7cf49cb2893ef60e8ab59dcac047
Author: Danielle Ratson <danieller@nvidia.com>
Date:   Thu Jun 27 17:08:51 2024 +0300

    ethtool: Add flashing transceiver modules' firmware notifications ability

    Add progress notifications ability to user space while flashing modules'
    firmware by implementing the interface between the user space and the
    kernel.

    Signed-off-by: Danielle Ratson <danieller@nvidia.com>
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
2024-10-01 12:19:13 +02:00
Ivan Vecera b0d7e2a017 ethtool: netlink: always pass genl_info to .prepare_data
JIRA: https://issues.redhat.com/browse/RHEL-30656

commit f946270d05c26044c67511ef5a9d91e06962d79f
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Aug 14 14:47:23 2023 -0700

    ethtool: netlink: always pass genl_info to .prepare_data

    We had a number of bugs in the past because developers forgot
    to fully test dumps, which pass NULL as info to .prepare_data.
    .prepare_data implementations would try to access info->extack
    leading to a null-deref.

    Now that dumps and notifications can access struct genl_info
    we can pass it in, and remove the info null checks.

    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # pause
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20230814214723.2924989-11-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2024-04-10 09:19:31 +02:00
Ivan Vecera 9bfc50f3f7 ethtool: netlink: convert commands to common SET
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2175237

commit 04007961bfaf76894b65de2af67f96d9d1fa82cf
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Jan 25 15:05:19 2023 -0800

    ethtool: netlink: convert commands to common SET

    Convert all SET commands where new common code is applicable.

    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2023-03-31 18:02:52 +02:00
Ivan Vecera 477a52d8e1 ethtool: use ethnl_parse_header_dev_put()
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2096377

commit 34ac17ecbf575eb079094d44f1bd30c66897aa21
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 14 00:42:30 2021 -0800

    ethtool: use ethnl_parse_header_dev_put()

    It seems I missed that most ethnl_parse_header_dev_get() callers
    declare an on-stack struct ethnl_req_info, and that they simply call
    dev_put(req_info.dev) when about to return.

    Add ethnl_parse_header_dev_put() helper to properly untrack
    reference taken by ethnl_parse_header_dev_get().

    Fixes: e4b8954074f6 ("netlink: add net device refcount tracker to struct ethnl_req_info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-06-13 18:39:15 +02:00
Ivan Vecera 9e88238cf8 ethtool: Add ability to control transceiver modules' power mode
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2047636

commit 353407d917b2d87cd8104a0453d012439c6ca4be
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Oct 6 13:46:42 2021 +0300

    ethtool: Add ability to control transceiver modules' power mode

    Add a pair of new ethtool messages, 'ETHTOOL_MSG_MODULE_SET' and
    'ETHTOOL_MSG_MODULE_GET', that can be used to control transceiver
    modules parameters and retrieve their status.

    The first parameter to control is the power mode of the module. It is
    only relevant for paged memory modules, as flat memory modules always
    operate in low power mode.

    When a paged memory module is in low power mode, its power consumption
    is reduced to the minimum, the management interface towards the host is
    available and the data path is deactivated.

    User space can choose to put modules that are not currently in use in
    low power mode and transition them to high power mode before putting the
    associated ports administratively up. This is useful for user space that
    favors reduced power consumption and lower temperatures over reduced
    link up times. In QSFP-DD modules the transition from low power mode to
    high power mode can take a few seconds and this transition is only
    expected to get longer with future / more complex modules.

    User space can control the power mode of the module via the power mode
    policy attribute ('ETHTOOL_A_MODULE_POWER_MODE_POLICY'). Possible
    values:

    * 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 via
    the 'ETHTOOL_A_MODULE_POWER_MODE' attribute. The attribute is not
    reported to user space when a module is not plugged-in.

    The user API is designed to be generic enough so that it could be used
    for modules with different memory maps (e.g., SFF-8636, CMIS).

    The only implementation of the device driver API in this series is for a
    MAC driver (mlxsw) where the module is controlled by the device's
    firmware, but it is designed to be generic enough so that it could also
    be 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                           : Off

    The 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 case
    LowPwrAllowRequestHW was on, the kernel would need to take into account
    the state of the LowPwrRequestHW signal, which is not visible to user
    space.

     $ ethtool --show-module swp11
     Module parameters for swp11:
     power-mode-policy high
     power-mode high

    Change the power mode policy to 'auto':

     # ethtool --set-module swp11 power-mode-policy auto

    Query the power mode again:

     $ ethtool --show-module swp11
     Module parameters for swp11:
     power-mode-policy auto
     power-mode low

    Verify 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                           : On

    Put the associated port administratively up which will instruct the host
    to transition the module to high power mode:

     # ip link set dev swp11 up

    Query the power mode again:

     $ ethtool --show-module swp11
     Module parameters for swp11:
     power-mode-policy auto
     power-mode high

    Verify 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                           : Off

    Put the associated port administratively down which will instruct the
    host to transition the module to low power mode:

     # ip link set dev swp11 down

    Query the power mode again:

     $ ethtool --show-module swp11
     Module parameters for swp11:
     power-mode-policy auto
     power-mode low

    Verify 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                           : On

    SFF-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 dBm

    The 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 override
    was off, the kernel would need to take into account the state of the
    LPMode signal, which is not visible to user space.

     $ ethtool --show-module swp13
     Module parameters for swp13:
     power-mode-policy high
     power-mode high

    Change the power mode policy to 'auto':

     # ethtool --set-module swp13 power-mode-policy auto

    Query the power mode again:

     $ ethtool --show-module swp13
     Module parameters for swp13:
     power-mode-policy auto
     power-mode low

    Verify 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 dBm

    Put the associated port administratively up which will instruct the host
    to transition the module to high power mode:

     # ip link set dev swp13 up

    Query the power mode again:

     $ ethtool --show-module swp13
     Module parameters for swp13:
     power-mode-policy auto
     power-mode high

    Verify 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 dBm

    Put the associated port administratively down which will instruct the
    host to transition the module to low power mode:

     # ip link set dev swp13 down

    Query the power mode again:

     $ ethtool --show-module swp13
     Module parameters for swp13:
     power-mode-policy auto
     power-mode low

    Verify 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 dBm

    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
2022-01-28 15:55:55 +01:00