Received: by 10.223.164.202 with SMTP id h10csp3215320wrb; Tue, 28 Nov 2017 07:54:35 -0800 (PST) X-Google-Smtp-Source: AGs4zMbzxw6y/BQKPDDh6xNodxxbcOWE1uJKmzNcwK91kbz+BG63uW8BuPMEnMgayS1HMMFZGcMj X-Received: by 10.98.65.197 with SMTP id g66mr41118200pfd.60.1511884475648; Tue, 28 Nov 2017 07:54:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511884475; cv=none; d=google.com; s=arc-20160816; b=xemmHP4cSGmIgnOoKZ8qwtGo9unltpVqVLieA6A/q+QmbGGmU2VrZPPRTX0pEQpCa5 pb/LVUzXmT3ZntKWQtwdBVyCMTwKjIx0iAjj2EMBEVnHt1epoxBH1bySC3oNCg/gqf0e VpoFYQWB1FSY3r2/GXqX7LvTxeREyQuk25seCy6P7qohmXyEhu4V/kkiWTVv/+MsRZd7 HcpENArFmf8v/pcWMb5NzXqpMoMM/FnbjNSsLTobCWAmNmsUxgXooDvSNUR8tFL0DygU JfjhhnZhxYZmarqw145rWTLEW/jO8or5PjiYdbxBPcnSOF8+K/tJBITpypG/lfRIoc9k I2xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=aKrJQDl0GBUzmCIG3L3pa6M2SO/vtg3+JAXAextUG80=; b=RCpEhlpYWrg+ZqqA9184euRyNkPcc+bFCKH1OZO6GlFqxDe49EybwnQJU900sEdEyt uywpO1igUK6N40BNZ85oyDnctGyQ6QSdUekD8dmOfvuCDPMpY6r6RWW4y32jQkaQGNAm RSX34FwUU/g0WPPsppHR1HLRhj72ZPVEiYY2id9MG0BH3f9uwJMXqGY9+ZLreH1gYkWO vJVMhm9TzWKp/vyc9lZi5QueRRCKjpczcaK7LGGHJ3+e4J78CD7XzbpG4Lo51qBIM0La qbB/nxOgocoLRryEF4W9R0p3Pet/lD7t440HcCurAhBvPZvMX6or+nUKSwAuIlbzgxK4 WjBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=SMhLOfNK; 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=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y16si23140575pgv.751.2017.11.28.07.54.23; Tue, 28 Nov 2017 07:54:35 -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; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=SMhLOfNK; 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=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754030AbdK1Pxm (ORCPT + 78 others); Tue, 28 Nov 2017 10:53:42 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:51664 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753738AbdK1Pxl (ORCPT ); Tue, 28 Nov 2017 10:53:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=aKrJQDl0GBUzmCIG3L3pa6M2SO/vtg3+JAXAextUG80=; b=SMhLOfNK5EXihEoq/MRNrrChypiMSUXhiMD/qUeOGzQtFY8FWKkSWeISl0Wxmngf6fTu1irA6hkOPSQJhhS0gl3YbpCVEKHmraj80upjRQgx1DvA5Tvkaj6zqiz2Ym9pelCu+mxeBWFa8Q0AyBRAiv2ARXfCpBuv1KoxaspsMPk=; Received: from flint.armlinux.org.uk ([2001:4d48:ad52:3201:201:2ff:fe14:8fad]:56386) by pandora.armlinux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eJiCK-0006hk-OJ; Tue, 28 Nov 2017 15:53:24 +0000 Received: from rmk by flint.armlinux.org.uk with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eJiCE-0002Ag-15; Tue, 28 Nov 2017 15:53:18 +0000 Date: Tue, 28 Nov 2017 15:53:17 +0000 From: Russell King 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, nadavh@marvell.com, mw@semihalf.com, stefanc@marvell.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: phylink: fix link state on phy-connect Message-ID: <20171128155317.GA7974@flint.armlinux.org.uk> References: <20171128132932.27196-1-antoine.tenart@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128132932.27196-1-antoine.tenart@free-electrons.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From 1585319272060571513@xxx Tue Nov 28 14:11:13 +0000 2017 X-GM-THRID: 1585316788419333533 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread