ethtool: Add QSFP-DD support

[popadi]

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   |
    +----------+----------+----------+----------+----------+----------

Several functions from qsfp.c could be reused, so an additional parameter
was added to each and the functions were moved to sff-common.c.

Signed-off-by: Adrian Pop [email protected]

[QiweiWen]

Hi Adrian,

Could you tell me the reason for reusing ETH_MODULE_SFF_8636 for QSFP-DD? I'm wondering because QSFP-DD is part of CMIS rather than SFF-8636 EEPROM standard, is there any advantage to reusing the module type number for QSFP?

Thanks,
Dave

[popadi]

@QiweiWen
Hi!
We are actually having an internal discussion about this at the moment. Not reusing ETH_MODULE_SFF_8636 would mean to define a new CMIS (something like ETH_MODULE_INF-8628) but that's gonna be correlated with a possible mainline driver that doesn't exist at the moment. So, to answer your question, no, there is no advantage to reusing the module type number for QSFP.

When I first worked at this patch for ethtool (in July this year) re-using ETH_MODULE_SFF_8636 seemed like a good idea, but now I feel some decisions have to be made and maybe not only for ethtool.

If you have any advice or ideas, feel free to share them. If you'd also like to contribute with comments to the mailing list (for this patch), feel free to jump in! (the patch is this, you can find there the message ID).