RE: [PATCH ethtool-next 0/4] Extend module EEPROM API

["Don Bollinger" <don@thebollingers.org>]

> From: Moshe Shemesh [mailto:moshe@nvidia.com]
> Sent: Friday, April 23, 2021 12:23 AM
> To: Michal Kubecek <mkubecek@suse.cz>; Andrew Lunn
> <andrew@lunn.ch>; Jakub Kicinski <kuba@kernel.org>; Don Bollinger
> <don@thebollingers.org>; netdev@vger.kernel.org
> Cc: Vladyslav Tarasiuk <vladyslavt@nvidia.com>; Moshe Shemesh
> <moshe@nvidia.com>
> Subject: [PATCH ethtool-next 0/4] Extend module EEPROM API
> 
> 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 adds support in `ethtool -m` of dumping an arbitrary page
> specified by page number, bank number and I2C address. Implement netlink
> handler for `ethtool -m` in order to make such requests to the kernel and
> extend CLI by adding corresponding parameters.
> New command line format:
>  ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N]
> [bank N] [i2c N]
> 
> Netlink infrastructure works on per-page basis and allows dumps of a
single
> page at once. But in case user requests human-readable output, which
> currently may require more than one page, userspace can make such
> additional calls to kernel on demand and place pages in a linked list.
> It allows to get pages from cache on demand and pass them to refactored
> SFF decoders.
> 
> Vladyslav Tarasiuk (4):
>   ethtool: Add netlink handler for getmodule (-m)
>   ethtool: Refactor human-readable module EEPROM output for new API
>   ethtool: Rename QSFP-DD identifiers to use CMIS 4.0
>   ethtool: Update manpages to reflect changes to getmodule (-m) command
> 
>  Makefile.am             |   3 +-
>  qsfp-dd.c => cmis4.c    | 220 +++++++++++---------
>  cmis4.h                 | 128 ++++++++++++
>  ethtool.8.in            |  14 ++
>  ethtool.c               |   4 +
>  internal.h              |  12 ++
>  list.h                  |  34 ++++
>  netlink/desc-ethtool.c  |  13 ++
>  netlink/extapi.h        |   2 +
>  netlink/module-eeprom.c | 438
> ++++++++++++++++++++++++++++++++++++++++
>  qsfp-dd.h               | 125 ------------
>  qsfp.c                  | 129 +++++++-----
>  qsfp.h                  |  52 ++---
>  sff-common.c            |   3 +
>  sff-common.h            |   3 +-
>  15 files changed, 876 insertions(+), 304 deletions(-)  rename qsfp-dd.c
=>
> cmis4.c (55%)  create mode 100644 cmis4.h  create mode 100644 list.h
create
> mode 100644 netlink/module-eeprom.c  delete mode 100644 qsfp-dd.h
> 
> --
> 2.26.2

Will there be an ethtool option to write to module eeprom in CMIS format?
There are routine functions to configure the devices that require writing
appropriate values to various registers.  Byte 26 allows software control of
low power mode, squelch and software reset.  Page 10h is full of Lane and
Data Path Control registers.

Beyond the spec, but allowed by the spec, there are vendor specific
capabilities like firmware download that require bulk write (up to 128 bytes
per write).

Using the full capabilities of these devices will require write capability.
Ethtool is the only path that will be allowed.

Don