From: Michael Walle <michael@walle.cc>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
cphealy@gmail.com, davem@davemloft.net, hkallweit1@gmail.com,
mkubecek@suse.cz, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v1 0/9] Ethernet Cable test support
Date: Thu, 30 Apr 2020 21:52:06 +0200 [thread overview]
Message-ID: <c840c633c6ce82e80c3db3b848e29ce3@walle.cc> (raw)
In-Reply-To: <8b01b2d8-39cb-dd10-e432-86d32284e12b@gmail.com>
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
next prev parent reply other threads:[~2020-04-30 19:52 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 18:06 [PATCH net-next v1 0/9] Ethernet Cable test support Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 1/9] net: phy: Add cable test support to state machine Andrew Lunn
2020-04-26 19:46 ` Michal Kubecek
2020-04-26 20:31 ` Andrew Lunn
2020-04-26 21:22 ` Florian Fainelli
2020-04-25 18:06 ` [PATCH net-next v1 2/9] net: phy: Add support for polling cable test Andrew Lunn
2020-04-25 19:49 ` Florian Fainelli
2020-04-25 20:10 ` Andrew Lunn
2020-04-26 21:19 ` Florian Fainelli
2020-04-26 22:07 ` Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 3/9] net: ethtool: netlink: Add support for triggering a " Andrew Lunn
2020-04-26 19:36 ` Michal Kubecek
2020-04-26 20:38 ` Andrew Lunn
2020-04-26 20:50 ` Michal Kubecek
2020-04-25 18:06 ` [PATCH net-next v1 4/9] net: ethtool: Add attributes for cable test reports Andrew Lunn
2020-04-25 20:00 ` Randy Dunlap
2020-04-26 20:25 ` Michal Kubecek
2020-04-26 21:12 ` Andrew Lunn
2020-04-27 7:13 ` Michal Kubecek
2020-04-29 16:16 ` Michael Walle
2020-04-29 18:57 ` Andrew Lunn
2020-04-29 18:58 ` Florian Fainelli
2020-04-29 19:32 ` Michael Walle
2020-04-25 18:06 ` [PATCH net-next v1 5/9] net: ethtool: Make helpers public Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 6/9] net: ethtool: Add infrastructure for reporting cable test results Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 7/9] net: ethtool: Add helpers for reporting " Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 8/9] net: phy: marvell: Add cable test support Andrew Lunn
2020-04-25 18:06 ` [PATCH net-next v1 9/9] net: phy: Put interface into oper testing during cable test Andrew Lunn
2020-04-29 16:02 ` [PATCH net-next v1 0/9] Ethernet Cable test support Michael Walle
2020-04-29 16:32 ` Andrew Lunn
2020-04-30 17:48 ` Michael Walle
2020-04-30 18:23 ` Andrew Lunn
2020-04-30 19:44 ` Michael Walle
2020-04-30 20:51 ` Andrew Lunn
2020-04-30 18:34 ` Florian Fainelli
2020-04-30 19:31 ` Michael Walle
2020-04-30 19:38 ` Florian Fainelli
2020-04-30 19:52 ` Michael Walle [this message]
2020-04-30 19:41 ` Andrew Lunn
2020-04-30 20:01 ` Michael Walle
2020-04-30 20:56 ` Andrew Lunn
2020-04-30 20:04 ` Florian Fainelli
2020-04-30 20:13 ` Michael Walle
2020-04-30 20:19 ` Florian Fainelli
2020-04-30 21:16 ` Michael Walle
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=c840c633c6ce82e80c3db3b848e29ce3@walle.cc \
--to=michael@walle.cc \
--cc=andrew@lunn.ch \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=mkubecek@suse.cz \
--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).