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]
Date:   Sun, 10 May 2020 16:51:26 +0200
From:   Michael Walle <michael@...le.cc>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 3/4] net: phy: broadcom: add cable test support

Am 2020-05-10 16:44, schrieb Andrew Lunn:
> On Sun, May 10, 2020 at 12:37:13AM +0200, Michael Walle wrote:
>> Most modern broadcom PHYs support ECD (enhanced cable diagnostics). 
>> Add
>> support for it in the bcm-phy-lib so they can easily be used in the 
>> PHY
>> driver.
>> 
>> There are two access methods for ECD: legacy by expansion registers 
>> and
>> via the new RDB registers which are exclusive. Provide functions in 
>> two
>> variants where the PHY driver can from. To keep things simple for now,
> 
> can from ?

can choose from. Should I send a new patch? Will DaveM fix minor typos, 
if
he commits it?

> 
>> +static int bcm_phy_report_length(struct phy_device *phydev, int 
>> result,
>> +				 int pair)
>> +{
>> +	int val;
>> +
>> +	val = __bcm_phy_read_exp(phydev,
>> +				 BCM54XX_EXP_ECD_PAIR_A_LENGTH_RESULTS + pair);
>> +	if (val < 0)
>> +		return val;
>> +
>> +	if (val == BCM54XX_ECD_LENGTH_RESULTS_INVALID)
>> +		return 0;
>> +
>> +	/* intra-pair shorts report twice the length */
>> +	if (result == BCM54XX_ECD_FAULT_TYPE_CROSS_SHORT)
>> +		val >>= 1;
> 
> You mentioned this before. This seems odd. The pulse travelled the
> same distance as for an open or shorted cable. The whole of time
> domain reflectrometry is based on some sort of echo and you always
> need to device by two. So why this special case?

Well, I don't know why this is special. But one thing which is
different is that you listen on all pairs for the pulse instead of
just the one where you've sent it (which seems to be a bit trickier
otherwise the cheapo AT8031 would support it, too). Maybe they
screwed that. In any case, I can try it with a 100m cable just
to be sure.

-michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ