Received: by 10.223.164.202 with SMTP id h10csp4771831wrb; Wed, 29 Nov 2017 11:34:44 -0800 (PST) X-Google-Smtp-Source: AGs4zMaeEIRaOm+mPCtmlO81GldOu5jvKZjhm3JDdEwpULHaZY0lCaURWGR6M/KFEHzqnskkrMQd X-Received: by 10.101.101.208 with SMTP id y16mr1877563pgv.159.1511984084182; Wed, 29 Nov 2017 11:34:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511984084; cv=none; d=google.com; s=arc-20160816; b=qlBJVfx4j8auotbhDBIMdFyicPj4W+tbbbe8B75TUngSnjPkaN1HRF6F3x5YGFk2G9 HhfIe7SLixYvUyKzOT1Vpm8yFBxCzomdd3czbfaHQ5U+SfQ5zCKkRNrf7k/cTQRNi5zT KT/LOxF9MDnsmEHMle2cRJ/nwrmZJG33bYPIGZQQCSErk1NTDXoUME/p7GpBJrkZnqfD hKnNv7ZaHx8gSHBnEed7+viQADo+mz12FHfoCnx4IWpyb+6jz2oQ3ejmWcEXbqSabjkS IVBYE+XimZj1scUH7V4Ajo3Z82yTTCud3MvyqVcgY+tx4ssaKAYZQW+IJvrp27PD4OSU 9wUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=t05jwSJ6Svy8tZyeJvRNmwbVrlB4UDLSGrtTPxJhwS4=; b=eSOBzeVcjaEwo8LA7OObVVTUSNUp9cV8iecHuSi4/nwI/mhgR0geUB+dez5ygbC/Lj 4wUXoPEDHK5KkLSuhzYE7PTCbw4OGiPMfoFtCoGt377qvnKxGIdqtsAhQeimiq+M+M9l kWgG6OBcD42NtzrdIbwsUJ4Mimj8WTf3uHFXZ2j+gQ0QRwQy9u2Ylrbhaitsqwmk/ynC HPl2cA6Y3WGoeKMlj8SmlQIl2pWbi+Qws/iuEVEHXjiDLcfDdFjJqCuINadnXt5gFtdh 84SPmGIlv+zy/FjN5aP2L69uoZrkcMdvMPkv8SZAm4mLtxMRQdARs8SXCGYIYBUN4NVK qrbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=marvell.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i35si1708641plg.516.2017.11.29.11.34.29; Wed, 29 Nov 2017 11:34:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=marvell.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752617AbdK2TeN convert rfc822-to-8bit (ORCPT + 99 others); Wed, 29 Nov 2017 14:34:13 -0500 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:54154 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751254AbdK2TeL (ORCPT ); Wed, 29 Nov 2017 14:34:11 -0500 Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vATJUNox026693; Wed, 29 Nov 2017 11:33:49 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 2egv7pp87c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Nov 2017 11:33:49 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Nov 2017 21:33:45 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Wed, 29 Nov 2017 21:33:44 +0200 From: Yan Markman To: Russell King , Antoine Tenart CC: "andrew@lunn.ch" , "f.fainelli@gmail.com" , "davem@davemloft.net" , "gregory.clement@free-electrons.com" , "thomas.petazzoni@free-electrons.com" , "miquel.raynal@free-electrons.com" , "Nadav Haklai" , "mw@semihalf.com" , "Stefan Chulski" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [EXT] Re: [PATCH net] net: phylink: fix link state on phy-connect Thread-Topic: [EXT] Re: [PATCH net] net: phylink: fix link state on phy-connect Thread-Index: AQHTaE0J1bz47nEl5EqXJeKzEHOhkKMpz+GAgAAA0ICAAeUZ0A== Date: Wed, 29 Nov 2017 19:33:44 +0000 Message-ID: <20448667430e434aad5bb8cd1b082611@IL-EXCH01.marvell.com> References: <20171128132932.27196-1-antoine.tenart@free-electrons.com> <20171128155317.GA7974@flint.armlinux.org.uk> <20171128155611.GA8358@flint.armlinux.org.uk> In-Reply-To: <20171128155611.GA8358@flint.armlinux.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.5.102.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-29_07:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290252 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Russel On my board I have [Marvell 88E1510] phy working with STATUS-POLLING I see some inconsistencies -- first ifconfig-up is different from furthers, no "link is down" reports. Please refer the behavior example below. My patch is a "simple solution" -- always reset/clear Link-state-parameters before going UP. Possibly, more correct (but much more complicated) solution would be in the phy state machine and phylink resolve modification. I just found that On ifconfig-down, the phy-state-machine and phylink-resolve are stopped before executing before passing over full graceful down/reset state. The further ifconfig-up starts with old state parameters. Special cases not-tested but logic 2 test-cases are: remote side changes speed whilst link is Down or Disconnected. But local ifconfig-up starts with old speed. Best regards Yan Markman ---------------------------------------------------- EXAMPLE: buildroot login: root ~# ifconfig eth1 192.169.0.81 up [ 34.072042] mvpp2 f2000000.ethernet eth1: PHY [f212a200.mdio-mii:01] driver [Marvell 88E1510] [ 34.080654] mvpp2 f2000000.ethernet eth1: configuring for phy/rgmii-id link mode [ 37.220506] mvpp2 f2000000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off ~# ifconfig eth1 down No print "link is down" ~# ifconfig eth1 up "Link is Up" passed twice: [ 60.748041] mvpp2 f2000000.ethernet eth1: PHY [f212a200.mdio-mii:01] driver [Marvell 88E1510] [ 60.756653] mvpp2 f2000000.ethernet eth1: configuring for phy/rgmii-id link mode [ 60.764169] mvpp2 f2000000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off [ 63.908504] mvpp2 f2000000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off On Link physical disconnect/break No print "link is down" But link is in correct state -- ifconfig UP but not-RUNNING On Link physical re-connect [ 84.388501] mvpp2 f2000000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off ------------------------------------------------------------------------------------------- YAN's findings: Best regards Yan Markman -----Original Message----- From: Russell King [mailto:rmk@armlinux.org.uk] Sent: Tuesday, November 28, 2017 5:56 PM To: Antoine Tenart Cc: andrew@lunn.ch; f.fainelli@gmail.com; davem@davemloft.net; Yan Markman ; gregory.clement@free-electrons.com; thomas.petazzoni@free-electrons.com; miquel.raynal@free-electrons.com; Nadav Haklai ; mw@semihalf.com; Stefan Chulski ; netdev@vger.kernel.org; linux-kernel@vger.kernel.org Subject: [EXT] Re: [PATCH net] net: phylink: fix link state on phy-connect External Email ---------------------------------------------------------------------- Oh, and lastly, please send patches to linux@armlinux.org.uk or the address I use in the sign-offs - sending them to rmk@armlinux.org.uk is for personal non-Linux mail only, and has resulted in _all_ of these messages ending up in my spam folder. Thanks. On Tue, Nov 28, 2017 at 03:53:17PM +0000, Russell King wrote: > On Tue, Nov 28, 2017 at 02:29:32PM +0100, Antoine Tenart wrote: > > From: Yan Markman > > Hi, thanks for the patch. > > > When calling successively _connect, _disconnect and _connect again, > > if the link configuration changed whilst being down from the phylink > > perspective, the last _connect would stay in an incorrect old speed. > > Fixes this by setting the link configuration parameters to an > > unknown value when calling phylink_bringup_phy. > > Under what circumstances does this occur? > > > > > Fixes: 9525ae83959b ("phylink: add phylink infrastructure") > > Signed-off-by: Yan Markman > > [Antoine: commit message] > > Signed-off-by: Antoine Tenart > > --- > > drivers/net/phy/phylink.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c > > index e3bbc70372d3..c2cec3eef67d 100644 > > --- a/drivers/net/phy/phylink.c > > +++ b/drivers/net/phy/phylink.c > > @@ -621,6 +621,16 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy) > > if (ret) > > return ret; > > > > + /* On _disconnect, the phy state machine and phylink resolve > > + * are stopped before executing full gracefull down/reset state. > > + * The further _connect starts with incorrect init state. Let's set > > + * init values here. > > + */ > > + pl->phy_state.link = false; > > + pl->link_config.pause = MLO_PAUSE_AN; > > + pl->link_config.speed = SPEED_UNKNOWN; > > + pl->link_config.duplex = DUPLEX_UNKNOWN; > > It would be much better to clean up the phy_state in > phylink_disconnect_phy() and trigger a resolve, rather than doing that > each time a PHY is connected - the link should be taken down when the > PHY is removed. > > However, I'd like to know under what circumstances this is happening, > since, if you're hotplugging a PHY you should be doing that via SFP > which has additional link up/down handling. What board is this with? > > Also note that there's a number of patches in my "phy" branch that I'm > intending to send as a result of working with Florian over the last > few weeks. There's several people working fairly independently in > this area and having everyone send patches independently of each other > could get painful to manage. > > I'm intending to send patches once I know that net-next is open. > > -- > Russell King > ARM architecture Linux Kernel maintainer -- Russell King ARM architecture Linux Kernel maintainer From 1585384189625679173@xxx Wed Nov 29 07:23:03 +0000 2017 X-GM-THRID: 1585316788419333533 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread