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 |
