Thread (9 messages) 9 messages, 4 authors, 2020-08-06

Re: [PATCH] ethtool: Add QSFP-DD support

From: Andrew Lunn <andrew@lunn.ch>
Date: 2020-08-02 16:55:17

On Fri, Jul 31, 2020 at 11:47:25AM +0300, Adrian Pop wrote:
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant information about an interface.

This patch adds QSFP-DD support to ethtool. The changes are similar to
the ones already existing in qsfp.c, but customized to use the memory
addresses and logic as defined in the specifications document.

Page 0x00 (lower and higher memory) are always implemented, so the ethtool
expects at least 256 bytes if the identifier matches the one for QSFP-DD.
For optical connected cables, additional pages are usually available (the
contain module defined  thresholds or lane diagnostic information). In
this case, ethtool expects to receive 768 bytes in the following format:

    +----------+----------+----------+----------+----------+----------+
    |   Page   |   Page   |   Page   |   Page   |   Page   |   Page   |
    |   0x00   |   0x00   |   0x01   |   0x02   |   0x10   |   0x11   |
    |  (lower) | (higher) | (higher) | (higher) | (higher) | (higher) |
    |   128B   |   128B   |   128B   |   128B   |   128B   |   128B   |
    +----------+----------+----------+----------+----------+----------
Hi Adrian

Didn't we discuss that page 3 might be useful? I would prefer not to
document that pages 0x10 and 0x11 would follow page 2 until we have a
driver which does actually provide pages 0x10 and 0x11.

       Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help