Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

[Andrew Lunn <andrew@lunn.ch>]

On Thu, Sep 27, 2018 at 04:08:24PM +0000, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and
> alarm indications from ethtool's output. It's worth mentioning
> that for me, the following fields always reported correctly
> as Off while no alarm condition was present
> and On while alarm condition(s) were present
> *per the QSFP's true/programmed threshold values*
> *not per the incorrectly reported threshold values*

These alarm values are in the first page. So the information the
driver returns does contain this information. What is missing is the
thresholds, which are not provided by the driver.

But there is a comment in the code:

        /*
         * There is no clear identifier to signify the existence of
         * optical diagnostics similar to SFF-8472. So checking existence
         * of page 3, will provide the gurantee for existence of alarms
         * and thresholds
         * If pagging support exists, then supports_alarms is marked as 1
         */

These alarm values are optional. The spec says so. So in order to
decide if they are implemented, ethtool looks to see if the thresholds
are available. If there are thresholds, it makes sense the alarms are
implemented.

Unfortunately, the driver never returns the thresholds. So ethtool has
no real choice and won't display the alarms since it cannot determine
if they are valid.

In order to get alarms, the driver needs to be extended to return all
the pages.

    Andrew