[net-next,v3,3/5] net: phy: update in-band AN mode when changing interface by PHY driver
Message ID | 20230921121946.3025771-4-yong.liang.choong@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5310069vqi; Thu, 21 Sep 2023 21:09:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG8wMCTx5miq0klg9ap15rTsha+pgBB3Rhj64QX5I+31rD3+Mij44rXJLMxkquxCaKIvJrW X-Received: by 2002:a17:90b:1482:b0:276:6be8:8bfe with SMTP id js2-20020a17090b148200b002766be88bfemr2360173pjb.23.1695355794176; Thu, 21 Sep 2023 21:09:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695355794; cv=none; d=google.com; s=arc-20160816; b=aInKjg3AIwVLvhdFssfctN9jydPh79KtZJxD3AEykJ0ELcWCt++Ec2o8ON2kdcBMrJ z8pavkuXcA9Qte0FAqkVXXWVu30nccGw/T4M93JtAgc7o2ZM27PT1G7ywhIl0+AtIjHI G98n6IuLwKFVbJnNsq31KMtN/udbzz1Ai6MyUB1//2Fp1VnmgyHO4Gz6EjpnHeSYryDv WWCa75x//2d2/7eIUSiXX5b11sXpg14Zh838/XMckeG3W0S4t4kMTDZHXVBED3pMdj6X GMfgxbSe0pWQ5GJs5D93Jo0J2E/Vs/4VH5ems4X++IvKvxGlJZSIKFiAaRP/klzw9WPX sh7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=5nBXgLxdjWJjAy0WR0VUxx/DOG46db7BYvmlXeAs6p4=; fh=eopC7/l+nVuh6mxtuaUTGuElFjyXo3EdPF+w+AmilC8=; b=Av0ZxBiSZjF9q7eIXvAMnZvpQCSF7L3NcI1KoI5wJaHI/wIyHMum2lR6AQL9emy3EP ioEY0wILxyUUiEamDS+9AEYbyLx4hge607QZsNXdzxXUqi/DFWgPggeCZiQfJQOYmz7N H29tN7P8gV3imDR/NK90xok3JMYK/2gqawacWiDusE7AF06KImUUPwLleEBZOZLQTuBy Pj4NpcMBxhOiAuiT1Z4DYyAMUXnISvgiVyvdbLYvU4bzL5H7WWNIZutdh9G/4ob6i/0o GrGQrAfGCG5h1hhud7Aq3nZcQud61NmOBcSmre0QuxsAaj9QpmTYxKP1/YVDPmz4GwZt dq4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KRDmTtOp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id hk18-20020a17090b225200b0027468369b4fsi5039156pjb.177.2023.09.21.21.09.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 21:09:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KRDmTtOp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 80EA68243BE1; Thu, 21 Sep 2023 13:01:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231504AbjIUUBE (ORCPT <rfc822;ruipengqi7@gmail.com> + 28 others); Thu, 21 Sep 2023 16:01:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229475AbjIUUAm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 21 Sep 2023 16:00:42 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46BE751F7B; Thu, 21 Sep 2023 10:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695316628; x=1726852628; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lTXXgtikZK8fOV2paXgb9h3Lt1o9zA5yS/eHowFJJOE=; b=KRDmTtOpSMmjsqzHqliaUmm1/gPNKHP9zItXGpAmm3GSIo190LktVyMS MFX+oi4UUxD/tcunceT50U5RjLrV8tAaSv1Z6P8VkiYRtIu731xR3Az8T rUx5ozMX+yj8aehngSm4fuE4u7vbINM+5ZnmxjuLXltnU+QcbWaFtoGXF uUtzUMlNM4C92ZoO1BbqKl2DCzmU2tke41q3asfKGXF/7d+49Yob3kYRb 7l+NH4DQowtbGOLKStDdHoPcl68w8b3voNcgpcTKzQqE7zTQWJxib5GXW W24uGTchsFLgpv7Ys2OQstkOaW83HA4cDQqHjOoX4t5m6l/duXBlavBiP w==; X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="444608265" X-IronPort-AV: E=Sophos;i="6.03,165,1694761200"; d="scan'208";a="444608265" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2023 05:20:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="862441935" X-IronPort-AV: E=Sophos;i="6.03,165,1694761200"; d="scan'208";a="862441935" Received: from yongliang-ubuntu20-ilbpg12.png.intel.com ([10.88.229.33]) by fmsmga002.fm.intel.com with ESMTP; 21 Sep 2023 05:20:48 -0700 From: Choong Yong Liang <yong.liang.choong@linux.intel.com> To: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>, David E Box <david.e.box@linux.intel.com>, Hans de Goede <hdegoede@redhat.com>, Mark Gross <markgross@kernel.org>, Jose Abreu <Jose.Abreu@synopsys.com>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, =?utf-8?q?Marek_Beh=C3=BAn?= <kabel@kernel.org>, Jean Delvare <jdelvare@suse.com>, Guenter Roeck <linux@roeck-us.net>, Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Richard Cochran <richardcochran@gmail.com>, Philipp Zabel <p.zabel@pengutronix.de>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Jesper Dangaard Brouer <hawk@kernel.org>, John Fastabend <john.fastabend@gmail.com>, Wong Vee Khee <veekhee@apple.com>, Jon Hunter <jonathanh@nvidia.com>, Jesse Brandeburg <jesse.brandeburg@intel.com>, Revanth Kumar Uppala <ruppala@nvidia.com>, Shenwei Wang <shenwei.wang@nxp.com>, Andrey Konovalov <andrey.konovalov@linaro.org>, Jochen Henneberg <jh@henneberg-systemdesign.com> Cc: David E Box <david.e.box@intel.com>, Andrew Halaney <ahalaney@redhat.com>, Simon Horman <simon.horman@corigine.com>, Bartosz Golaszewski <bartosz.golaszewski@linaro.org>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-hwmon@vger.kernel.org, bpf@vger.kernel.org, Voon Wei Feng <weifeng.voon@intel.com>, Tan Tee Min <tee.min.tan@linux.intel.com>, Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>, Lai Peter Jun Ann <jun.ann.lai@intel.com> Subject: [PATCH net-next v3 3/5] net: phy: update in-band AN mode when changing interface by PHY driver Date: Thu, 21 Sep 2023 20:19:44 +0800 Message-Id: <20230921121946.3025771-4-yong.liang.choong@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230921121946.3025771-1-yong.liang.choong@linux.intel.com> References: <20230921121946.3025771-1-yong.liang.choong@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 21 Sep 2023 13:01:23 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777672237400704148 X-GMAIL-MSGID: 1777709397351023172 |
Series |
TSN auto negotiation between 1G and 2.5G
|
|
Commit Message
Choong Yong Liang
Sept. 21, 2023, 12:19 p.m. UTC
As there is a mechanism in PHY drivers to switch the PHY interface
between SGMII and 2500BaseX according to link speed. In this case,
the in-band AN mode should be switching based on the PHY interface
as well, if the PHY interface has been changed/updated by PHY driver.
For e.g., disable in-band AN in 2500BaseX mode, or enable in-band AN
back for SGMII mode (10/100/1000Mbps).
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
---
drivers/net/phy/phylink.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
Comments
On 21/9/2023 10:04 pm, Russell King (Oracle) wrote: > On Thu, Sep 21, 2023 at 08:19:44PM +0800, Choong Yong Liang wrote: >> As there is a mechanism in PHY drivers to switch the PHY interface >> between SGMII and 2500BaseX according to link speed. In this case, >> the in-band AN mode should be switching based on the PHY interface >> as well, if the PHY interface has been changed/updated by PHY driver. >> >> For e.g., disable in-band AN in 2500BaseX mode, or enable in-band AN >> back for SGMII mode (10/100/1000Mbps). >> >> Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> > > This approach is *going* to break existing setups, sorry. > >> +/** >> + * phylink_interface_change() - update both cfg_link_an_mode and >> + * cur_link_an_mode when there is a change in the interface. >> + * @phydev: pointer to &struct phy_device >> + * >> + * When the PHY interface switches between SGMII and 2500BaseX in >> + * accordance with the link speed, the in-band AN mode should also switch >> + * based on the PHY interface >> + */ >> +static void phylink_interface_change(struct phy_device *phydev) >> +{ >> + struct phylink *pl = phydev->phylink; >> + >> + if (pl->phy_state.interface != phydev->interface) { >> + /* Fallback to the correct AN mode. */ >> + if (phy_interface_mode_is_8023z(phydev->interface) && >> + pl->cfg_link_an_mode == MLO_AN_INBAND) { >> + pl->cfg_link_an_mode = MLO_AN_PHY; >> + pl->cur_link_an_mode = MLO_AN_PHY; > > 1. Why are you changing both cfg_link_an_mode (configured link AN mode) > and cur_link_an_mode (current link AN mode) ? > > The "configured" link AN mode is supposed to be whatever was configured > at phylink creation time, and it's never supposed to change. The > "current" link AN mode can change, but changing that must be followed > by a major reconfiguration to ensure everything is correctly setup. > That will happen only because the change to the current link AN mode > can only happen when pl->phy_state.interface has changed, and the > change of pl->phy_state.interface triggers the reconfiguration. > During the phylink_create, the cfg_link_an_mode will be set to MLO_AN_INBAND. Then we switch from the SGMII interface to 2500BASEX interface. When we perform 'ifconfig eth0 down' and 'ifconfig eth0 up' then we will not able to bring up the PHY due to the phylink_attach_phy function. It is not expect to have MLO_AN_INBAND with PHY_INTERFACE_MODE_2500BASEX interface. static int phylink_attach_phy(struct phylink *pl, struct phy_device *phy, phy_interface_t interface) { if (WARN_ON(pl->cfg_link_an_mode == MLO_AN_FIXED || (pl->cfg_link_an_mode == MLO_AN_INBAND && phy_interface_mode_is_8023z(interface) && !pl->sfp_bus))) return -EINVAL; if (pl->phydev) return -EBUSY; return phy_attach_direct(pl->netdev, phy, 0, interface); } I did change different ways to handle it in the new patch series. So it should not impact much on the existing phylink framework. > 2. You force this behaviour on everyone, so now everyone with a SFP > module that operates in 802.3z mode will be switched out of inband mode > whether they want that or not. This is likely to cause some breakage. > >> + } else if (pl->config->ovr_an_inband) { >> + pl->cfg_link_an_mode = MLO_AN_INBAND; >> + pl->cur_link_an_mode = MLO_AN_INBAND; > > Here you force inband when not 802.3z mode and ovr_an_inband is set. > There are SFP modules that do *not* support in-band at all, and this > will break these modules when combined with a driver that sets > ovr_an_inband. So more breakage. > > Please enumerate the PHY interface modes that you are trying to support > with this patch set, and indicate whether you want in-band for that > mode or not, and where the restriction for whether in-band can be used > comes from (PHY, PCS or MAC) so that it's possible to better understand > what you're trying to achieve. > > Thanks. > Thank you for pointing out the bug that will impact everyone. Actually cur_link_an_mode is just required for PCS, I did handle it that only intel platforms will get the PCS negotiation mode for the PCS.
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 0d7354955d62..5811c8086149 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -1723,6 +1723,34 @@ bool phylink_expects_phy(struct phylink *pl) } EXPORT_SYMBOL_GPL(phylink_expects_phy); +/** + * phylink_interface_change() - update both cfg_link_an_mode and + * cur_link_an_mode when there is a change in the interface. + * @phydev: pointer to &struct phy_device + * + * When the PHY interface switches between SGMII and 2500BaseX in + * accordance with the link speed, the in-band AN mode should also switch + * based on the PHY interface + */ +static void phylink_interface_change(struct phy_device *phydev) +{ + struct phylink *pl = phydev->phylink; + + if (pl->phy_state.interface != phydev->interface) { + /* Fallback to the correct AN mode. */ + if (phy_interface_mode_is_8023z(phydev->interface) && + pl->cfg_link_an_mode == MLO_AN_INBAND) { + pl->cfg_link_an_mode = MLO_AN_PHY; + pl->cur_link_an_mode = MLO_AN_PHY; + } else if (pl->config->ovr_an_inband) { + pl->cfg_link_an_mode = MLO_AN_INBAND; + pl->cur_link_an_mode = MLO_AN_INBAND; + } + + pl->phy_state.interface = phydev->interface; + } +} + static void phylink_phy_change(struct phy_device *phydev, bool up) { struct phylink *pl = phydev->phylink; @@ -1739,7 +1767,7 @@ static void phylink_phy_change(struct phy_device *phydev, bool up) pl->phy_state.pause |= MLO_PAUSE_TX; if (rx_pause) pl->phy_state.pause |= MLO_PAUSE_RX; - pl->phy_state.interface = phydev->interface; + phylink_interface_change(phydev); pl->phy_state.link = up; mutex_unlock(&pl->state_mutex);