netdev - Re: [RFC net-next] net: phy: at803x: add cable diagnostics support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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