Re: signal quality and cable diagnostic

[Andrew Lunn <andrew@lunn.ch>]

> > As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
> > and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
> > parameters like this in which case we may want to consider adding new
> > request type (e.g. link params or link management).
> 
> Currently in my short term todo are:
> - SQI


> - PHY undervoltage
> - PHY overtemerature

Do you only have alarms? Or are current values available for voltage
and temperature?

Both of these would fit hwmon. It even has the option to set the alarm
thresholds. The advantage of hwmon is that they are then just more
sensors. You could even include the temperature sensor into a thermal
zone to influence cooling. There are a couple of PHYs which already do
hwmon, so there is code you can copy.

> So far, I have no idea for PHY health diagnostic.
> 
> If we consider at least the  mandatory properties listed in the opensig, then
> we would get following list:
> 
> - DCQ (dynamic channel group)
>   - SQI (Signal Quality Index)
> - HDD (Harness defect detection group)
>   - OS (Open/Short detection) ----------------- implemented, cable test
>     request.
> - LQ (Link Quality)
>   - LTT (Link-training time. The time of the last link training)
>   - LFL (Link Failures and Losses. Number of link losses since the last
>     power cycle)
>   - COM (communication ready) ----------------- implemented?
> - POL (Polarity detection & correction)
>   - DET (Polarity detect)

Voltage and temperature are about the package. These are about the
link. So they better fit ETHTOOL_MSG_LINKINFO_SET or similar.

It sounds like LFL are statistic counters? PHYs can have their own
counters, which ethtool -S will return.

Does POLL somehow map to MDI MDIX? I guess not, since this is a T1.

     Andrew