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
