lkml.org 
[lkml]   [2020]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: signal quality and cable diagnostic
On Mon, May 11, 2020 at 04:59:26PM +0200, Michal Kubecek wrote:
> On Mon, May 11, 2020 at 04:13:10PM +0200, Oleksij Rempel wrote:
> >
> > I continue to work on TJA11xx PHY and need to export some additional
> > cable diagnostic/link stability information: Signal Quality Index (SQI).
> > The PHY data sheet describes it as following [1]:
> > ================================================================================
> > 6.10.3 Link stability
> >
> > The signal-to-noise ratio is the parameter used to estimate link
> > stability. The PMA Receive function monitors the signal-to-noise ratio
> > continuously. Once the signal-to-noise ratio falls below a configurable
> > threshold (SQI_FAILLIMIT), the link status is set to FAIL and
> > communication is interrupted. The TJA1100 allows for adjusting the
> > sensitivity of the PMA Receive function by configuring this threshold.
> > The microcontroller can always check the current value of the
> > signal-to-noise ratio via the SMI, allowing it to track a possible
> > degradation in link stability.
> > ================================================================================
> >
> > Since this functionality is present at least on TJA11xx PHYs and
> > mandatory according to Open Alliance[2], I hope this functionality is
> > present on other 100/1000Base-T1 PHYs. So may be some common abstraction
> > is possible. What would be the best place to provide it for the user
> > space? According to the [2] SQI, is the part of Dynamic Channel Quality
> > (DCQ) together with Mean Square Error (MSE) and Peak MSE value (pMSE).
>
> IIUC these would be read-only parameters describing current state of the
> link which can be queried at any time. If this is the case, adding them
> as attributes to ETHTOOL_MSG_LINKSTATE_GET_REPLY message seems most
> fitting.

ok

> 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

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)

I personally would add RE_ERR counter in this list as well.

Probably some one, soon or later, will try to implement them.

If I see it correctly, some of this properties are already implemented
within other request types. Is it worth to a add a new request type for
the rest of them?

Regards,
Oleksij

--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

\
 
 \ /
  Last update: 2020-05-12 08:50    [W:0.172 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site