mbox series

[net-next,0/8] ethtool: Extend module EEPROM dump API

Message ID 1617955601-21055-1-git-send-email-moshe@nvidia.com (mailing list archive)
Headers show
Series ethtool: Extend module EEPROM dump API | expand

Message

Moshe Shemesh April 9, 2021, 8:06 a.m. UTC
Ethtool supports module EEPROM dumps via the `ethtool -m <dev>` command.
But in current state its functionality is limited - offset and length
parameters, which are used to specify a linear desired region of EEPROM
data to dump, is not enough, considering emergence of complex module
EEPROM layouts such as CMIS 4.0.
Moreover, CMIS 4.0 extends the amount of pages that may be accessible by
introducing another parameter for page addressing - banks.

Besides, currently module EEPROM is represented as a chunk of
concatenated pages, where lower 128 bytes of all pages, except page 00h,
are omitted. Offset and length are used to address parts of this fake
linear memory. But in practice drivers, which implement
get_module_info() and get_module_eeprom() ethtool ops still calculate
page number and set I2C address on their own.

This series tackles these issues by adding ethtool op, which allows to
pass page number, bank number and I2C address in addition to offset and
length parameters to the driver, adds corresponding netlink
infrastructure and implements the new interface in mlx5 driver.

This allows to extend userspace 'ethtool -m' CLI by adding new
parameters - page, bank and i2c. New command line format:
 ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N] [bank N] [i2c N]

The consequence of this series is a possibility to dump arbitrary EEPROM
page at a time, in contrast to dumps of concatenated pages. Therefore,
offset and length change their semantics and may be used only to specify
a part of data within half page boundary, which size is currently limited
to 128 bytes.

As for drivers that support legacy get_module_info() and
get_module_eeprom() pair, the series addresses it by implementing a
fallback mechanism. As mentioned earlier, such drivers derive a page
number from 'global' offset, so this can be done vice versa without
their involvement thanks to standardization. If kernel netlink handler
of 'ethtool -m' command detects that new ethtool op is not supported by
the driver, it calculates offset from given page number and page offset
and calls old ndos, if they are available.

Change log:
RFC v5 -> v1:
- Added support for generic SFP (by Andrew).
- Fixd fallback code by exporting functions ethtool_get_module_eeprom_call()
  and ethtool_get_module_info_call() (by Andrew).
- Fix ETH_MODULE_EEPROM_PAGE_LEN in fallback to
  ETH_MODULE_EEPROM_PAGE_LEN * 2 when accounting for high I2C.

RFC v4 -> RFC v5:
- Limited KAPI to only read 1/2 page at once.
- Redefined ETH_MODULE_EEPROM_PAGE_LEN as 128.
- Made page number mandatory for any request.
- Added extack messages for invalid parameters failures.

RFC v3 -> RFC v4:
- Renamed many identifiers to use 'eeprom' instead of 'eeprom_data'.
- Renamed netlink enums and defines to use 'MODULE_EEPROM' instead of
   'EEPROM_DATA'.
- Renamed struct ethtool_eeprom_data to ethtool_module_eeprom.
- Added MODULE_EEPROM_MAX_OFFSET (257 * 256) macro and check global offset
    against it to avoid overflow.
- Removed ndo pointer check from _parse_request().
- Removed separate length element from netlink response.
- Limited reads to 128 bytes without crossing half page bound.

RFC v2 -> RFC v3:
- Removed page number limitations
- Added length limit when page is present in fallback
- Changed page, bank and i2c_address type to u8 all over the patchset
- Added 0x51 I2C address usage increasing offset by 256 for SFP

RFC v1 -> RFC v2:
- Limited i2c_address values by 127
- Added page bound check for offset and length
- Added defines for these two points
- Added extack to ndo parameters
- Moved ethnl_ops_begin(dev) and set error path accordingly


Andrew Lunn (3):
  net: ethtool: Export helpers for getting EEPROM info
  phy: sfp: add netlink SFP support to generic SFP code
  ethtool: wire in generic SFP module access

Vladyslav Tarasiuk (5):
  ethtool: Allow network drivers to dump arbitrary EEPROM data
  net/mlx5: Refactor module EEPROM query
  net/mlx5: Implement get_module_eeprom_by_page()
  net/mlx5: Add support for DSFP module EEPROM dumps
  ethtool: Add fallback to get_module_eeprom from netlink command

 Documentation/networking/ethtool-netlink.rst  |  36 ++-
 .../ethernet/mellanox/mlx5/core/en_ethtool.c  |  44 ++++
 .../net/ethernet/mellanox/mlx5/core/port.c    | 110 ++++++--
 drivers/net/phy/sfp-bus.c                     |  20 ++
 drivers/net/phy/sfp.c                         |  25 ++
 drivers/net/phy/sfp.h                         |   3 +
 include/linux/ethtool.h                       |  33 ++-
 include/linux/mlx5/port.h                     |  12 +
 include/linux/sfp.h                           |  10 +
 include/uapi/linux/ethtool_netlink.h          |  19 ++
 net/ethtool/Makefile                          |   2 +-
 net/ethtool/common.h                          |   5 +
 net/ethtool/eeprom.c                          | 246 ++++++++++++++++++
 net/ethtool/ioctl.c                           |  14 +-
 net/ethtool/netlink.c                         |  11 +
 net/ethtool/netlink.h                         |   2 +
 16 files changed, 553 insertions(+), 39 deletions(-)
 create mode 100644 net/ethtool/eeprom.c

Comments

patchwork-bot+netdevbpf@kernel.org April 12, 2021, 12:10 a.m. UTC | #1
Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Fri, 9 Apr 2021 11:06:33 +0300 you wrote:
> Ethtool supports module EEPROM dumps via the `ethtool -m <dev>` command.
> But in current state its functionality is limited - offset and length
> parameters, which are used to specify a linear desired region of EEPROM
> data to dump, is not enough, considering emergence of complex module
> EEPROM layouts such as CMIS 4.0.
> Moreover, CMIS 4.0 extends the amount of pages that may be accessible by
> introducing another parameter for page addressing - banks.
> 
> [...]

Here is the summary with links:
  - [net-next,1/8] ethtool: Allow network drivers to dump arbitrary EEPROM data
    https://git.kernel.org/netdev/net-next/c/c781ff12a2f3
  - [net-next,2/8] net/mlx5: Refactor module EEPROM query
    https://git.kernel.org/netdev/net-next/c/e19b0a3474ab
  - [net-next,3/8] net/mlx5: Implement get_module_eeprom_by_page()
    https://git.kernel.org/netdev/net-next/c/e109d2b204da
  - [net-next,4/8] net/mlx5: Add support for DSFP module EEPROM dumps
    https://git.kernel.org/netdev/net-next/c/4c88fa412a10
  - [net-next,5/8] net: ethtool: Export helpers for getting EEPROM info
    https://git.kernel.org/netdev/net-next/c/95dfc7effd88
  - [net-next,6/8] ethtool: Add fallback to get_module_eeprom from netlink command
    https://git.kernel.org/netdev/net-next/c/96d971e307cc
  - [net-next,7/8] phy: sfp: add netlink SFP support to generic SFP code
    https://git.kernel.org/netdev/net-next/c/d740513f05a2
  - [net-next,8/8] ethtool: wire in generic SFP module access
    https://git.kernel.org/netdev/net-next/c/c97a31f66ebc

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html