[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c09c5c851e64f374fe9f7f575113f432@walle.cc>
Date: Wed, 06 May 2020 12:15:01 +0200
From: Michael Walle <michael@...le.cc>
To: Matthias May <matthias.may@...atec.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [RFC net-next] net: phy: at803x: add cable diagnostics support
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
Powered by blists - more mailing lists