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:   Thu, 19 Mar 2020 08:30:58 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: phy: add and use phy_check_downshift

On 19.03.2020 00:21, Russell King - ARM Linux admin wrote:
> On Wed, Mar 18, 2020 at 10:29:01PM +0100, Heiner Kallweit wrote:
>> So far PHY drivers have to check whether a downshift occurred to be
>> able to notify the user. To make life of drivers authors a little bit
>> easier move the downshift notification to phylib. phy_check_downshift()
>> compares the highest mutually advertised speed with the actual value
>> of phydev->speed (typically read by the PHY driver from a
>> vendor-specific register) to detect a downshift.
> 
> My personal position on this is that reporting a downshift will be
> sporadic at best, even when the link has negotiated slower.
> 
> The reason for this is that either end can decide to downshift.  If
> the remote partner downshifts, then the local side has no idea that
> a downshift occurred, and can't report that the link was downshifted.
> 
Right, this warning can't cover the case that remote link partner
downshifts. In this case however ethtool et al should show the reduced
link partner advertisement, and therefore provide a hint why speed
is slow.

> So, is it actually useful to report these events?
> 
To provide an example: A user recently complained that r8169 driver
makes problems on his system:
- it takes long time until link comes up
- link is slow
With iperf he then found out that displayed speed is 1Gbps but actual
link speed is 100Mbps. In the end he found that one pin of his network
port was corroded, therefore the downshift.

The phase of blaming the driver could have been skipped if he would
have seen a downshift warning from the very beginning.

>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>> ---
>>  drivers/net/phy/phy-core.c | 33 +++++++++++++++++++++++++++++++++
>>  drivers/net/phy/phy.c      |  1 +
>>  include/linux/phy.h        |  1 +
>>  3 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
>> index e083e7a76..8e861be73 100644
>> --- a/drivers/net/phy/phy-core.c
>> +++ b/drivers/net/phy/phy-core.c
>> @@ -329,6 +329,39 @@ void phy_resolve_aneg_linkmode(struct phy_device *phydev)
>>  }
>>  EXPORT_SYMBOL_GPL(phy_resolve_aneg_linkmode);
>>  
>> +/**
>> + * phy_check_downshift - check whether downshift occurred
>> + * @phydev: The phy_device struct
>> + *
>> + * Check whether a downshift to a lower speed occurred. If this should be the
>> + * case warn the user.
>> + */
>> +bool phy_check_downshift(struct phy_device *phydev)
>> +{
>> +	__ETHTOOL_DECLARE_LINK_MODE_MASK(common);
>> +	int i, speed = SPEED_UNKNOWN;
>> +
>> +	if (phydev->autoneg == AUTONEG_DISABLE)
>> +		return false;
>> +
>> +	linkmode_and(common, phydev->lp_advertising, phydev->advertising);
>> +
>> +	for (i = 0; i < ARRAY_SIZE(settings); i++)
>> +		if (test_bit(settings[i].bit, common)) {
>> +			speed = settings[i].speed;
>> +			break;
>> +		}
>> +
>> +	if (phydev->speed == speed)
>> +		return false;
>> +
>> +	phydev_warn(phydev, "Downshift occurred from negotiated speed %s to actual speed %s, check cabling!\n",
>> +		    phy_speed_to_str(speed), phy_speed_to_str(phydev->speed));
>> +
>> +	return true;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_check_downshift);
>> +
>>  static int phy_resolve_min_speed(struct phy_device *phydev, bool fdx_only)
>>  {
>>  	__ETHTOOL_DECLARE_LINK_MODE_MASK(common);
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index d71212a41..067ff5fec 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -507,6 +507,7 @@ static int phy_check_link_status(struct phy_device *phydev)
>>  		return err;
>>  
>>  	if (phydev->link && phydev->state != PHY_RUNNING) {
>> +		phy_check_downshift(phydev);
>>  		phydev->state = PHY_RUNNING;
>>  		phy_link_up(phydev);
>>  	} else if (!phydev->link && phydev->state != PHY_NOLINK) {
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index cb5a2182b..4962766b2 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -698,6 +698,7 @@ static inline bool phy_is_started(struct phy_device *phydev)
>>  
>>  void phy_resolve_aneg_pause(struct phy_device *phydev);
>>  void phy_resolve_aneg_linkmode(struct phy_device *phydev);
>> +bool phy_check_downshift(struct phy_device *phydev);
>>  
>>  /**
>>   * phy_read - Convenience function for reading a given PHY register
>> -- 
>> 2.25.1
>>
>>
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ