netdev - Re: [PATCH net-next 07/10] r8169: migrate speed

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 3 Jul 2018 09:48:24 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 07/10] r8169: migrate speed_down function to
 phylib



On 07/02/2018 02:31 PM, Heiner Kallweit wrote:
> On 02.07.2018 23:20, Andrew Lunn wrote:
>>  On Mon, Jul 02, 2018 at 09:37:08PM +0200, Heiner Kallweit wrote:
>>> Change rtl_speed_down() to use phylib.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>>> ---
>>>  drivers/net/ethernet/realtek/r8169.c | 33 +++++++++++++---------------
>>>  1 file changed, 15 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
>>> index 311321ee..807fbc75 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -4240,6 +4240,10 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
>>>  		rtl_writephy(tp, 0x0b, 0x0000); //w 0x0b 15 0 0
>>>  	}
>>>  
>>> +	/* We may have called rtl_speed_down before */
>>> +	dev->phydev->advertising = dev->phydev->supported;
>>> +	genphy_config_aneg(dev->phydev);
>>> +
>>>  	genphy_soft_reset(dev->phydev);
>>>  
>>>  	rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
>>> @@ -4323,28 +4327,21 @@ static void rtl_init_mdio_ops(struct rtl8169_private *tp)
>>>  	}
>>>  }
>>>  
>>> +#define BASET10		(ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full)
>>> +#define BASET100	(ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full)
>>> +#define BASET1000	(ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full)
>>> +
>>>  static void rtl_speed_down(struct rtl8169_private *tp)
>>>  {
>>> -	u32 adv;
>>> -	int lpa;
>>> +	struct phy_device *phydev = tp->dev->phydev;
>>> +	u32 adv = phydev->lp_advertising & phydev->supported;
>>>  
>>> -	rtl_writephy(tp, 0x1f, 0x0000);
>>> -	lpa = rtl_readphy(tp, MII_LPA);
>>> +	if (adv & BASET10)
>>> +		phydev->advertising &= ~(BASET100 | BASET1000);
>>> +	else if (adv & BASET100)
>>> +		phydev->advertising &= ~BASET1000;
>>>  
>>> -	if (lpa & (LPA_10HALF | LPA_10FULL))
>>> -		adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full;
>>> -	else if (lpa & (LPA_100HALF | LPA_100FULL))
>>> -		adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
>>> -		      ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full;
>>> -	else
>>> -		adv = ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
>>> -		      ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
>>> -		      (tp->mii.supports_gmii ?
>>> -		       ADVERTISED_1000baseT_Half |
>>> -		       ADVERTISED_1000baseT_Full : 0);
>>> -
>>> -	rtl8169_set_speed(tp->dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
>>> -			  adv);
>>> +	genphy_config_aneg(phydev);
>>>  }
>>
>> It probably it is me being too tired, but i don't get what this is
>> doing? Changing the local advertisement based on what the remote is
>> advertising. Why?
>>
> It also took me some time to understand what this speed_down is doing.
> If we suspend and wait for a WoL packet, then we don't have to burn all
> the energy for a GBit connection. Therefore we switch to the lowest
> speed supported by chip and link partner. This is done by removing
> higher speeds from the advertised modes and restarting an autonego.

This is something that the tg3 driver also does, we should probably
consider doing this as part of a generic PHY library helpers since I was
told by several HW engineers that usually 10Mbits for WoL is much more
energy efficient.

One thing that bothers me a bit is that this should ideally be offered
as both blocking and non-blocking options, because we might want to make
sure that at the time we suspend, and we already had a link established,
we successfully re-negotiate the link with the partner. I agree that
there could be any sort of link disruption happening at any point though..
-- 
Florian