Message-ID: <c840c633c6ce82e80c3db3b848e29ce3@walle.cc>
Date:   Thu, 30 Apr 2020 21:52:06 +0200
From:   Michael Walle <michael@...le.cc>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, 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

Am 2020-04-30 21:38, schrieb Florian Fainelli:
> On 4/30/20 12:31 PM, Michael Walle wrote:
>> Hi Florian,
>> 
>> Am 2020-04-30 20:34, schrieb Florian Fainelli:
>>> 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?
>> 
>> ECD. The registers looks exactly like the one from the Marvell PHYs,
>> which makes me wonder if both have the same building block or if one
>> imitated the registers of the other. There are subtle differences
>> like one bit in the broadcom PHY is "break link" and is self-clearing,
>> while the bit on the Marvell PHY is described as "perform diagnostics
>> on link break".
>> 
>> I don't know what simple cable diagnostics should be, I guess the
>> BCM54140 doesn't support it or its not documented. Actually, ECD
>> has very little documentation in general.
> 
> Yes, there is very little information, even internally. My 
> understanding
> is that diagnostics at run at auto-neg, so you need to break the link,
> and when the link comes back up is when you should have per-pair
> results. There are also some caveats, like the link parnter must also
> have auto-negotiation on for the diagnostics to work.

Ok, that was also my guess.

>>> 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.
>> 
>> What do you mean by calibrate it?
> 
> You need to tune the AFE and DSP of the PHY in order for it to report
> accurate cable lengths. I would not think that you have access to that,
> and what I got access to is not really well documented, which is why I
> have not had a chance to submit those changes yet.
> 
> How accurate are your results when there is no link?

I've only tested with a ~100m cable (or two in a row). The results were
104m to 107m.

-michael

Powered by blists - more mailing lists