From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: Marek Vasut <marex@denx.de>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
mkl@pengutronix.de, kernel@pengutronix.de,
David Jander <david@protonic.nl>,
Jakub Kicinski <kuba@kernel.org>,
Christian Herber <christian.herber@nxp.com>,
"David S. Miller" <davem@davemloft.net>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: signal quality and cable diagnostic
Date: Tue, 12 May 2020 08:48:58 +0200 [thread overview]
Message-ID: <20200512064858.GA16536@pengutronix.de> (raw)
In-Reply-To: <20200511145926.GC8503@lion.mk-sys.cz>
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 |
next prev parent reply other threads:[~2020-05-12 6:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 14:13 signal quality and cable diagnostic Oleksij Rempel
2020-05-11 14:33 ` Andrew Lunn
2020-05-12 8:22 ` Oleksij Rempel
2020-05-12 8:54 ` Robert Schwebel
2020-05-14 7:13 ` [EXT] " Christian Herber
2020-05-14 8:28 ` Oleksij Rempel
2020-05-11 14:59 ` Michal Kubecek
2020-05-12 6:48 ` Oleksij Rempel [this message]
2020-05-12 13:04 ` Andrew Lunn
2020-05-24 21:28 ` Pavel Machek
2020-05-14 8:42 Christian Herber
2020-05-24 21:27 ` Pavel Machek
2020-05-24 22:42 ` Russell King - ARM Linux admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200512064858.GA16536@pengutronix.de \
--to=o.rempel@pengutronix.de \
--cc=andrew@lunn.ch \
--cc=christian.herber@nxp.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=david@protonic.nl \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marex@denx.de \
--cc=mkl@pengutronix.de \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).