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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b63498f01e64c55124c2c710fffb1047@walle.cc>
Date:   Thu, 30 Apr 2020 22:13:42 +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 22:04, schrieb Florian Fainelli:
> On 4/30/20 12:41 PM, Andrew Lunn wrote:
>>> 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".
>> 
>> Should we be sharing code between the two drivers?
> 
> Yes, I am amazed how how identical they are, nearly on a bit level
> identical, the coincidence is uncanny. The expansion registers are also
> 0x10 - 0x15 just in the reverse order,

At what PHY are you looking? I've just found some datasheets where they
are at 0xC0 to 0xC5.

> you know, so as to make it not
> too obvious this looks about the same ;) I wonder if we managed to find
> something here.
> 
>> 
>>> What do you mean by calibrate it?
>> 
>> Some of the Marvell documentation talks about calibrating for losses
>> on the PCB. Run a diagnostics with no cable plugged in, and get the
>> cable length to the 'fault'. This gives you the distance to the RJ45
>> socket. You should then subtract that from all subsequent results.
>> But since this is board design specific, i decided to ignore it. I
>> suppose it could be stuffed into a DT property, but i got the feeling
>> it is not worth it, given the measurement granularity of 80cm.
> 
> OK, accuracy is different here, they are said to be +/- 5m accurate for
> cable faults and +/- 10m accurate for good cables.

Accuracy != granularity. But yes, if one digit correspond to 80cm it
doesn't really make sense to remove the PCB trace error if you assume
that it might add just one digit at most.

-michael