netdev - Re: [PATCH net-next v1 0/9] Ethernet Cable test 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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 30 Apr 2020 11:34:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Michael Walle <michael@...le.cc>, Andrew Lunn <andrew@...n.ch>
Cc:     cphealy@...il.com, davem@...emloft.net, hkallweit1@...il.com,
        mkubecek@...e.cz, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 0/9] Ethernet Cable test support

On 4/30/20 10:48 AM, Michael Walle wrote:
> Hi Andrew,
> 
> Am 2020-04-29 18:32, schrieb Andrew Lunn:
>> On Wed, Apr 29, 2020 at 06:02:13PM +0200, Michael Walle wrote:
>>> Hi Andrew,
>>>
>>> > Add infrastructure in ethtool and phylib support for triggering a
>>> > cable test and reporting the results. The Marvell 1G PHY driver is
>>> > then extended to make use of this infrastructure.
>>>
>>> I'm currently trying this with the AR8031 PHY. With this PHY, you
>>> have to select the pair which you want to start the test on. So
>>> you'd have to start the test four times in a row for a normal
>>> gigabit cable. Right now, I don't see a way how to do that
>>> efficiently if there is no interrupt. One could start another test
>>> in the get_status() polling if the former was completed
>>> successfully. But then you'd have to wait at least four polling
>>> intervals to get the final result (given a cable with four pairs).
>>>
>>> Any other ideas?
>>
>> Hi Michael
>>
>> Nice to see some more PHYs getting support for this.
>>
>> It is important that the start function returns quickly. However, the
>> get status function can block. So you could do all the work in the
>> first call to get status, polling for completion at a faster rate,
>> etc.
> 
> Ok. I do have one problem. TDR works fine for the AR8031 and the
> BCM54140 as long as there is no link partner, i.e. open cable,
> shorted pairs etc. But as soon as there is a link partner and a
> link, both PHYs return garbage. As far as I understand TDR, there
> must not be a link, correct? The link partner may send data or
> link pulses. No how do you silence the local NIC or even the peer?

Michael do you use the enhanced cable diagnostics (ECD) or the simple
cable diagnostics? Having tried to get older Broadcom PHYs to work with
cable diagnostics, you need to calibrate the PHY prior to running
diagnostics and you need to soft reset it.
-- 
Florian