From: Michael Walle <michael@walle.cc>
To: Matthias May <matthias.may@neratec.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [RFC net-next] net: phy: at803x: add cable diagnostics support
Date: Wed, 06 May 2020 12:15:01 +0200 [thread overview]
Message-ID: <c09c5c851e64f374fe9f7f575113f432@walle.cc> (raw)
In-Reply-To: <00e8202e-1786-27f4-3bfc-accc5a01787d@neratec.com>
Am 2020-05-06 11:01, schrieb Matthias May:
> I've worked with this PHY quite often and we've hacked together some
> support for the CDT in uboot.
>
> Have you done any tests with the cable on the other side being plugged
> in?
yes
>
> With the cable being plugged in, we something (1 out of 10 or so)
> observed that the test returns with a failure.
> --> AT803X_CDT_STATUS_STAT_FAIL in AT803X_CDT_STATUS
>
> Often you get the correct result if you simply try again. Sometimes
> however it gets into a "stuck" state where it just
> returns FAIL for ~3~10 seconds. After some that it seems to recover
> and gets the correct result again.
its actually pretty stable for the following sequence (see also code
above):
restart AN -> wait 1.5s -> start test
Only thing I've noticed is that if you perform the test without
waiting for the AN to complete beforehand there might be some
failed states. Seems like the "restart an" doesn't work while
AN is still running. But that seems to be the link partner
who disturbs the measurement.
And it seems that AN is a requirement to do successful testing
(or to silence the link partner I guess).
-michael
prev parent reply other threads:[~2020-05-06 10:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 18:15 [RFC net-next] net: phy: at803x: add cable diagnostics support Michael Walle
2020-05-05 13:07 ` Andrew Lunn
2020-05-05 14:20 ` Michael Walle
2020-05-06 9:01 ` Matthias May
2020-05-06 10:15 ` Michael Walle [this message]
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=c09c5c851e64f374fe9f7f575113f432@walle.cc \
--to=michael@walle.cc \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.may@neratec.com \
--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).