| Message ID | 20211006104647.2357115-1-idosch@idosch.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ethtool: Add ability to control transceiver modules' power mode | expand |
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Wed, 6 Oct 2021 13:46:41 +0300 you wrote: > From: Ido Schimmel <idosch@nvidia.com> > > This patchset extends the ethtool netlink API to allow user space to > control transceiver modules. Two specific APIs are added, but the plan > is to extend the interface with more APIs in the future (see "Future > plans"). > > [...] Here is the summary with links: - [net-next,v2,1/6] ethtool: Add ability to control transceiver modules' power mode applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/353407d917b2 - [net-next,v2,2/6] mlxsw: reg: Add Port Module Memory Map Properties register applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/f10ba086f7e3 - [net-next,v2,3/6] mlxsw: reg: Add Management Cable IO and Notifications register applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/fc53f5fb8037 - [net-next,v2,4/6] mlxsw: Add ability to control transceiver modules' power mode applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/0455dc50bcca - [net-next,v2,5/6] ethtool: Add transceiver module extended state applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/3dfb51126064 - [net-next,v2,6/6] mlxsw: Add support for transceiver module extended state applied by Jakub Kicinski <kuba@kernel.org> https://git.kernel.org/netdev/net-next/c/235dbbec7d72 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
From: Ido Schimmel <idosch@nvidia.com> This patchset extends the ethtool netlink API to allow user space to control transceiver modules. Two specific APIs are added, but the plan is to extend the interface with more APIs in the future (see "Future plans"). This submission is a complete rework of a previous submission [1] that tried to achieve the same goal by allowing user space to write to the EEPROMs of these modules. It was rejected as it could have enabled user space binary blob drivers. However, the main issue is that by directly writing to some pages of these EEPROMs, we are interfering with the entity that is controlling the modules (kernel / device firmware). In addition, some functionality cannot be implemented solely by writing to the EEPROM, as it requires the assertion / de-assertion of hardware signals (e.g., "ResetL" pin in SFF-8636). Motivation ========== The kernel can currently dump the contents of module EEPROMs to user space via the ethtool legacy ioctl API or the new netlink API. These dumps can then be parsed by ethtool(8) according to the specification that defines the memory map of the EEPROM. For example, SFF-8636 [2] for QSFP and CMIS [3] for QSFP-DD. In addition to read-only elements, these specifications also define writeable elements that can be used to control the behavior of the module. For example, controlling whether the module is put in low or high power mode to limit its power consumption. The CMIS specification even defines a message exchange mechanism (CDB, Command Data Block) on top of the module's memory map. This allows the host to send various commands to the module. For example, to update its firmware. Implementation ============== The ethtool netlink API is extended with two new messages, 'ETHTOOL_MSG_MODULE_SET' and 'ETHTOOL_MSG_MODULE_GET', that allow user space to set and get transceiver module parameters. Specifically, the 'ETHTOOL_A_MODULE_POWER_MODE_POLICY' attribute allows user space to control the power mode policy of the module in order to limit its power consumption. See detailed description in patch #1. 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 kernel. Testing and introspection ========================= See detailed description in patches #1 and #5. Patchset overview ================= Patch #1 adds the initial infrastructure in ethtool along with the ability to control transceiver modules' power mode. Patches #2-#3 add required device registers in mlxsw. Patch #4 implements in mlxsw the ethtool operations added in patch #1. Patch #5 adds extended link states in order to allow user space to troubleshoot link down issues related to transceiver modules. Patch #6 adds support for these extended states in mlxsw. Future plans ============ * Extend 'ETHTOOL_MSG_MODULE_SET' to control Tx output among other attributes. * Add new ethtool message(s) to update firmware on transceiver modules. * Extend ethtool(8) to parse more diagnostic information from CMIS modules. No kernel changes required. Changes since v1 [4]: * Patch #1: Set ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH to 1 and remove validity bit. * Patch #1: Avoid calling set_module_power_mode() if policy did not change. Changes since RFC v3 [5]: * Patch #1: Fix comment indentation. * Patch #1: Rephrase paragraph about default power mode policy. * Patch #1: Remove ethtool_module_power_mode_params::mode_valid. * Patch #1: Set ETHTOOL_MODULE_POWER_MODE_LOW to 1. * Patch #1: Add a new paragraph in "Conventions" section. * Patch #2: Add "sticky" bit. Changes since RFC v2 [6]: * Change 'high-on-up' power mode policy to 'auto'. * Remove 'low' power mode policy. * Document that default power mode policy is driver-dependent. * Remove restrictions regarding interface administrative state when setting the power mode policy. Changes since RFC v1 [7]: * Split 'ETHTOOL_A_MODULE_LOW_POWER_ENABLED' into two attributes. * Add 'high-on-up' power mode policy. * Drop 'ETHTOOL_MSG_MODULE_RESET_ACT' in favor of existing ioctl interface. * Add extended link states to help in troubleshooting. [1] https://lore.kernel.org/netdev/20210623075925.2610908-1-idosch@idosch.org/ [2] https://members.snia.org/document/dl/26418 [3] http://www.qsfp-dd.com/wp-content/uploads/2021/05/CMIS5p0.pdf [4] https://lore.kernel.org/netdev/20211003073219.1631064-1-idosch@idosch.org/ [5] https://lore.kernel.org/netdev/20210824130344.1828076-1-idosch@idosch.org/ [6] https://lore.kernel.org/netdev/20210818155202.1278177-1-idosch@idosch.org/ [7] https://lore.kernel.org/netdev/20210809102152.719961-1-idosch@idosch.org/ Ido Schimmel (6): ethtool: Add ability to control transceiver modules' power mode mlxsw: reg: Add Port Module Memory Map Properties register mlxsw: reg: Add Management Cable IO and Notifications register mlxsw: Add ability to control transceiver modules' power mode ethtool: Add transceiver module extended state mlxsw: Add support for transceiver module extended state Documentation/networking/ethtool-netlink.rst | 81 +++++++- .../net/ethernet/mellanox/mlxsw/core_env.c | 193 +++++++++++++++++- .../net/ethernet/mellanox/mlxsw/core_env.h | 10 + drivers/net/ethernet/mellanox/mlxsw/minimal.c | 26 +++ drivers/net/ethernet/mellanox/mlxsw/reg.h | 84 ++++++++ .../mellanox/mlxsw/spectrum_ethtool.c | 35 ++++ include/linux/ethtool.h | 23 +++ include/uapi/linux/ethtool.h | 29 +++ include/uapi/linux/ethtool_netlink.h | 17 ++ net/ethtool/Makefile | 2 +- net/ethtool/module.c | 180 ++++++++++++++++ net/ethtool/netlink.c | 19 ++ net/ethtool/netlink.h | 4 + 13 files changed, 697 insertions(+), 6 deletions(-) create mode 100644 net/ethtool/module.c