Message ID | 20230330091404.3293431-2-michael.wei.hong.sit@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp995402vqo; Thu, 30 Mar 2023 02:32:13 -0700 (PDT) X-Google-Smtp-Source: AKy350Y5+C2bR1TrHL3bd0tFJrFuXe2hzz6Dvq5viHqeH/EqFAHWdo8B7hM2lH2gjD+v4o0lb27I X-Received: by 2002:a17:906:1514:b0:92b:ae6c:23e7 with SMTP id b20-20020a170906151400b0092bae6c23e7mr22310149ejd.56.1680168733176; Thu, 30 Mar 2023 02:32:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680168733; cv=none; d=google.com; s=arc-20160816; b=PPEjWEaYfHPbrzsoCWNN5hQRU337nzGnDcehxJmw89J8nZq6LrSMjEsqGHavfpJ6jM CxDJqcmQRqHp+aRsV8hXFOtemZAgxTGnoz4MzNOXaOrS1TpXRAlovjXKY9X8gWL/mVOE Vw4IwczCJ0vvARh2PzYNCF37eQCvggwonQjMTsNJjrFTLYGkL0TqwQyW+pMa/w80qHuc aj8tygMlp5KE26YDfwW+KoApmSct7+cF9Js8koeLus3ecXbfY5ZxM1k3kre9SSVuolOh 0+a8ax1VKYv3JGEMzwlHkDUOVDmSqTkQF8ndX4LvHbO6ngt53xv2Q4/E//h33F6/PTLn Nvtw== 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=4HPaR5A53quMi2uxB6Lwfp7K0MJyZzMxL3dhXe+02Rw=; b=LVEdUQwWcMPyJL1hfNqCn6S4cJ0ru68RoNYMjY9tyd514YDMfofusTW2NcqxYrhEBL WuWX8wMuCGMYCM5C4M4JJf3g+i642fbxieviCl1xuUTbOOJOdQJnf6O1au/3989YboTU pU4VTuFAAcgWyE+/f5hRiwhz1ehzzA/1XXybaHht9RcGj6RfIhTq0dI7gC4442suKbte Mg0TR6nQr0ayMBe+H6GCpDwNnzmFxg10YntFYOwIe26wK7caH1LYxoURd751nHy3gpBc Fp94lIr10OvGG7H+px5KHWPwXVRLhUtK4iHQql8xTsPFeCK8VaAWEjojvluzBeVRIDJu MbCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gVOX11q6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qf7-20020a1709077f0700b00947335f538asi70765ejc.211.2023.03.30.02.31.48; Thu, 30 Mar 2023 02:32:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gVOX11q6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229862AbjC3JPS (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Thu, 30 Mar 2023 05:15:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229639AbjC3JPG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Mar 2023 05:15:06 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 476F21738; Thu, 30 Mar 2023 02:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680167705; x=1711703705; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EQDSnthQ5cFmTJaAo9m1vejrcveOKhLU44+A2MCijjk=; b=gVOX11q6H70AC9mktoatnHzTOk5Bjd35ksjMv06igVEsKFK6TrnGj5Sq 1qPpKKvIuN9D/DDM/gGmk+TVq3R7OHBehVXJsZhxG8PM5EPaI5Vt1c2Pj k3OUA8n9rlsJkeWxyUmtIc/HUwN7bywGW42VtiKuIlwZ57+bc5IPwIy8l sJ0ndKQiPJwZZ8lYDiQDpx6NXgL2O0cSxDrcKlPu7it6MlGeooiVGJCjI zYRtSNb+inpryjWPVwH55flBCJ6wpyjaSg8sx2FI4TPcD+GA4TzyQkEnf KZoxuVASUBLILcDKr7shdeegvgvJoU41aZyJ/JDQLoIElA1Dsw5VKOGUr A==; X-IronPort-AV: E=McAfee;i="6600,9927,10664"; a="325038866" X-IronPort-AV: E=Sophos;i="5.98,303,1673942400"; d="scan'208";a="325038866" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2023 02:15:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10664"; a="678125408" X-IronPort-AV: E=Sophos;i="5.98,303,1673942400"; d="scan'208";a="678125408" Received: from mike-ilbpg1.png.intel.com ([10.88.227.76]) by orsmga007.jf.intel.com with ESMTP; 30 Mar 2023 02:14:52 -0700 From: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> To: Giuseppe Cavallaro <peppe.cavallaro@st.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Ong Boon Leong <boon.leong.ong@intel.com>, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux@armlinux.org.uk, hkallweit1@gmail.com, andrew@lunn.ch Cc: Looi Hong Aun <hong.aun.looi@intel.com>, Voon Weifeng <weifeng.voon@intel.com>, Lai Peter Jun Ann <peter.jun.ann.lai@intel.com> Subject: [PATCH net v5 1/3] net: phylink: add phylink_expects_phy() method Date: Thu, 30 Mar 2023 17:14:02 +0800 Message-Id: <20230330091404.3293431-2-michael.wei.hong.sit@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230330091404.3293431-1-michael.wei.hong.sit@intel.com> References: <20230330091404.3293431-1-michael.wei.hong.sit@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761784609358345574?= X-GMAIL-MSGID: =?utf-8?q?1761784609358345574?= |
Series |
Fix PHY handle no longer parsing
|
|
Commit Message
Sit, Michael Wei Hong
March 30, 2023, 9:14 a.m. UTC
Provide phylink_expects_phy() to allow MAC drivers to check if it is expecting a PHY to attach to. Since fixed-linked setups do not need to attach to a PHY. Provides a boolean value as to if the MAC should expect a PHY. Returns true if a PHY is expected. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> --- drivers/net/phy/phylink.c | 19 +++++++++++++++++++ include/linux/phylink.h | 1 + 2 files changed, 20 insertions(+)
Comments
> -----Original Message----- > From: Maxime Chevallier <maxime.chevallier@bootlin.com> > Sent: Wednesday, April 12, 2023 4:38 PM > To: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>; Alexandre > Torgue <alexandre.torgue@foss.st.com>; Jose Abreu > <joabreu@synopsys.com>; David S . Miller <davem@davemloft.net>; > Eric Dumazet <edumazet@google.com>; Jakub Kicinski > <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Maxime > Coquelin <mcoquelin.stm32@gmail.com>; Ong, Boon Leong > <boon.leong.ong@intel.com>; netdev@vger.kernel.org; linux- > stm32@st-md-mailman.stormreply.com; linux-arm- > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > linux@armlinux.org.uk; hkallweit1@gmail.com; andrew@lunn.ch; > Looi, Hong Aun <hong.aun.looi@intel.com>; Voon, Weifeng > <weifeng.voon@intel.com>; Lai, Peter Jun Ann > <peter.jun.ann.lai@intel.com>; alexis.lothore@bootlin.com > Subject: Re: [PATCH net v5 1/3] net: phylink: add > phylink_expects_phy() method > > Hello everyone, > > On Thu, 30 Mar 2023 17:14:02 +0800 > Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> wrote: > > > Provide phylink_expects_phy() to allow MAC drivers to check if it is > > expecting a PHY to attach to. Since fixed-linked setups do not need > to > > attach to a PHY. > > > > Provides a boolean value as to if the MAC should expect a PHY. > > Returns true if a PHY is expected. > > I'm currently working on the TSE rework for dwmac_socfpga, and I > noticed one regression since this patch, when using an SFP, see > details below : > > > Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > > Signed-off-by: Michael Sit Wei Hong > <michael.wei.hong.sit@intel.com> > > --- > > drivers/net/phy/phylink.c | 19 +++++++++++++++++++ > > include/linux/phylink.h | 1 + > > 2 files changed, 20 insertions(+) > > > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c > > index 1a2f074685fa..30c166b33468 100644 > > --- a/drivers/net/phy/phylink.c > > +++ b/drivers/net/phy/phylink.c > > @@ -1586,6 +1586,25 @@ void phylink_destroy(struct phylink > *pl) } > > EXPORT_SYMBOL_GPL(phylink_destroy); > > > > +/** > > + * phylink_expects_phy() - Determine if phylink expects a phy to > be > > attached > > + * @pl: a pointer to a &struct phylink returned from > phylink_create() > > + * > > + * When using fixed-link mode, or in-band mode with 1000base-X > or > > 2500base-X, > > + * no PHY is needed. > > + * > > + * Returns true if phylink will be expecting a PHY. > > + */ > > +bool phylink_expects_phy(struct phylink *pl) { > > + if (pl->cfg_link_an_mode == MLO_AN_FIXED || > > + (pl->cfg_link_an_mode == MLO_AN_INBAND && > > + phy_interface_mode_is_8023z(pl->link_config.interface))) > > From the discussion, at one point Russell mentionned [1] : > "If there's a sfp bus, then we don't expect a PHY from the MAC > driver (as there can only be one PHY attached), and as > phylink_expects_phy() is for the MAC driver to use, we should be > returning false if > pl->sfp_bus != NULL." > > This makes sense and indeed adding the relevant check solves the > issue. > > Am I correct in assuming this was an unintentional omission from > this patch, or was the pl->sfp_bus check dropped on purpose ? > > > + return false; > > + return true; > > +} > > +EXPORT_SYMBOL_GPL(phylink_expects_phy); > > Thanks, > > Maxime > Russell also did mention: " The reason for the extra "&& !pl->sfp_bus" in phylink_attach_phy() is to allow SFPs to connect to the MAC using inband mode with 1000base-X and 2500base-X interface modes. These are not for the MAC-side of things though." So I thought that the check can be dropped. I do not have any SFP hardware to test, if adding the check make sense, you can send us a patch so we can test it out. > [1] : > https://lore.kernel.org/netdev/ZCQJWcdfmualIjvX@shell.armlinux.o > rg.uk/
Hello everyone, On Thu, 30 Mar 2023 17:14:02 +0800 Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> wrote: > Provide phylink_expects_phy() to allow MAC drivers to check if it > is expecting a PHY to attach to. Since fixed-linked setups do not > need to attach to a PHY. > > Provides a boolean value as to if the MAC should expect a PHY. > Returns true if a PHY is expected. I'm currently working on the TSE rework for dwmac_socfpga, and I noticed one regression since this patch, when using an SFP, see details below : > Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> > Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> > --- > drivers/net/phy/phylink.c | 19 +++++++++++++++++++ > include/linux/phylink.h | 1 + > 2 files changed, 20 insertions(+) > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c > index 1a2f074685fa..30c166b33468 100644 > --- a/drivers/net/phy/phylink.c > +++ b/drivers/net/phy/phylink.c > @@ -1586,6 +1586,25 @@ void phylink_destroy(struct phylink *pl) > } > EXPORT_SYMBOL_GPL(phylink_destroy); > > +/** > + * phylink_expects_phy() - Determine if phylink expects a phy to be > attached > + * @pl: a pointer to a &struct phylink returned from phylink_create() > + * > + * When using fixed-link mode, or in-band mode with 1000base-X or > 2500base-X, > + * no PHY is needed. > + * > + * Returns true if phylink will be expecting a PHY. > + */ > +bool phylink_expects_phy(struct phylink *pl) > +{ > + if (pl->cfg_link_an_mode == MLO_AN_FIXED || > + (pl->cfg_link_an_mode == MLO_AN_INBAND && > + phy_interface_mode_is_8023z(pl->link_config.interface))) From the discussion, at one point Russell mentionned [1] : "If there's a sfp bus, then we don't expect a PHY from the MAC driver (as there can only be one PHY attached), and as phylink_expects_phy() is for the MAC driver to use, we should be returning false if pl->sfp_bus != NULL." This makes sense and indeed adding the relevant check solves the issue. Am I correct in assuming this was an unintentional omission from this patch, or was the pl->sfp_bus check dropped on purpose ? > + return false; > + return true; > +} > +EXPORT_SYMBOL_GPL(phylink_expects_phy); Thanks, Maxime [1] : https://lore.kernel.org/netdev/ZCQJWcdfmualIjvX@shell.armlinux.org.uk/
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 1a2f074685fa..30c166b33468 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -1586,6 +1586,25 @@ void phylink_destroy(struct phylink *pl) } EXPORT_SYMBOL_GPL(phylink_destroy); +/** + * phylink_expects_phy() - Determine if phylink expects a phy to be attached + * @pl: a pointer to a &struct phylink returned from phylink_create() + * + * When using fixed-link mode, or in-band mode with 1000base-X or 2500base-X, + * no PHY is needed. + * + * Returns true if phylink will be expecting a PHY. + */ +bool phylink_expects_phy(struct phylink *pl) +{ + if (pl->cfg_link_an_mode == MLO_AN_FIXED || + (pl->cfg_link_an_mode == MLO_AN_INBAND && + phy_interface_mode_is_8023z(pl->link_config.interface))) + return false; + return true; +} +EXPORT_SYMBOL_GPL(phylink_expects_phy); + static void phylink_phy_change(struct phy_device *phydev, bool up) { struct phylink *pl = phydev->phylink; diff --git a/include/linux/phylink.h b/include/linux/phylink.h index c492c26202b5..637698ed5cb6 100644 --- a/include/linux/phylink.h +++ b/include/linux/phylink.h @@ -574,6 +574,7 @@ struct phylink *phylink_create(struct phylink_config *, struct fwnode_handle *, phy_interface_t iface, const struct phylink_mac_ops *mac_ops); void phylink_destroy(struct phylink *); +bool phylink_expects_phy(struct phylink *pl); int phylink_connect_phy(struct phylink *, struct phy_device *); int phylink_of_phy_connect(struct phylink *, struct device_node *, u32 flags);