lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 May 2020 15:04:18 +0200
From:   Andrew Lunn <>
To:     Oleksij Rempel <>
Cc:     Michal Kubecek <>, Marek Vasut <>,
        Florian Fainelli <>,
        Jonathan Corbet <>,,, Russell King <>,,,
        David Jander <>,
        Jakub Kicinski <>,
        Christian Herber <>,
        "David S. Miller" <>,
        Heiner Kallweit <>
Subject: Re: signal quality and cable diagnostic

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


Powered by blists - more mailing lists