Message ID | 20230324081656.2969663-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 b10csp468376vqo; Fri, 24 Mar 2023 01:45:29 -0700 (PDT) X-Google-Smtp-Source: AKy350awH8tXKVnhmAircjAXuP0uVUjcAILUYwVqCIGRvRDvTXdAb5chPBh5lChl88fmBwVhKjb6 X-Received: by 2002:a17:906:e0c5:b0:931:4f2c:4e83 with SMTP id gl5-20020a170906e0c500b009314f2c4e83mr1822329ejb.63.1679647529235; Fri, 24 Mar 2023 01:45:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679647529; cv=none; d=google.com; s=arc-20160816; b=eom96cIVbLjIlDfsYY2l4zM8C2XFxRzkeMc9XZJYMIe7D59DKvcePpadkU5M7ghblG E9m7YPjWNQEHEepBtmeX/YvOX5XC1F7loNrkBGeJqNdKu+ojB2nFS9TVnBSCRUyliLp/ JU7h2qQ1aTACcE/0Tq9ssI5R9b3aCu8hahc+L0m3QzDp7Q5vfFJsE4nvnBbEJV8DnErx /tTdWKAz1lPJzRpXAIb6EnLvw5JuN8WVwCScSf75FIC45Nuvbhx9rOjG/+kOqV54lIFC huwiVT8eJ+DRN6uGYE+u4Z72Tgz9rx6PMVNusmnQkoJlvfz2fPYMUPMoVd06NimcfMAc ROdw== 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=BXb1nkBpUTAX8yrpBdxs34C49hnCCJAqCIo5kHlT/+o=; b=sBw3M7NjGefcFlcFKu0mM17O0UOPgJdxDvwoV8VISARFSKkHAlvordE7Hwc3YqlM3O SnsCmbHKssuIUu47xT11MUR6Sd/qbakMvba3fymJ/WU4SO8a1B77M08jh23iGKosLMFT rmCQfwD7hNm7XHwNH5y8OZKiY6tBn4Zhl+RmtBmMT65Gvx6x73UE6Pv2I56vTLUyT8BO 5wKyR8MAXfW2ut+2dzeEhFUKQChH5adu3i0jWg0dHh5Pcvtvf4XiiZk4GKEkH8ffFggd VMUdQJTpGPDGOzSpu/t65eSSVP8Nsg6FEbQF8MyCzuJna9iBHuD0wJPgmwAC9fa0mBbl 4spw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XWlX2aiI; 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 21-20020a170906225500b0092554df06ffsi22334401ejr.286.2023.03.24.01.45.05; Fri, 24 Mar 2023 01:45:29 -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=XWlX2aiI; 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 S231362AbjCXIRo (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Fri, 24 Mar 2023 04:17:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229753AbjCXIRm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Mar 2023 04:17:42 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B6CE24705; Fri, 24 Mar 2023 01:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679645861; x=1711181861; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=7zEf318EIZQVC7Yb173ekmxTq+Dw6hKeKqmHqTYHp78=; b=XWlX2aiI0mu0vuIvgxk4TtNpg2rHKvr4Q+kzU4EN3TLENUqAFATZjKbV 3fbSq8vGcH9X8xyfqdUcxBvyuzPK7SCk2zi/gKjET++dxAGok4zXoKWVu +WV3vv7lej0JvAw79oktNnTHLw85XPd4oDI6a492wp10YgJAf+miSdIKm L0zeu/jwFvpbjORv2bV6gSwIQ0K5IyjHsCKrctgSP43eJiuZRUPS9Geaj ubV5yh1o4KHwu/ifawz+nGCXu1dFrSUEyBnw3vqCV8/PMWBYxVmhULFuE qbDeHStI+1hRmJ0wXH7PCMrFDemOBW6otyN9DaPQS5rgGUUD8mRrVsbFK Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10658"; a="320116081" X-IronPort-AV: E=Sophos;i="5.98,287,1673942400"; d="scan'208";a="320116081" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2023 01:17:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10658"; a="928574701" X-IronPort-AV: E=Sophos;i="5.98,287,1673942400"; d="scan'208";a="928574701" Received: from mike-ilbpg1.png.intel.com ([10.88.227.76]) by fmsmga006.fm.intel.com with ESMTP; 24 Mar 2023 01:17:37 -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 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 v3 1/3] net: phylink: add phylink_expects_phy() method Date: Fri, 24 Mar 2023 16:16:54 +0800 Message-Id: <20230324081656.2969663-2-michael.wei.hong.sit@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230324081656.2969663-1-michael.wei.hong.sit@intel.com> References: <20230324081656.2969663-1-michael.wei.hong.sit@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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?1761238087509951289?= X-GMAIL-MSGID: =?utf-8?q?1761238087509951289?= |
Series |
Fix PHY handle no longer parsing
|
|
Commit Message
Sit, Michael Wei Hong
March 24, 2023, 8:16 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.
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>
---
drivers/net/phy/phylink.c | 13 +++++++++++++
include/linux/phylink.h | 1 +
2 files changed, 14 insertions(+)
Comments
On Fri, 24 Mar 2023 16:16:54 +0800 Michael Sit Wei Hong 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. > > Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Russell, looks good? > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c > index 1a2f074685fa..5c2bd1370993 100644 > --- a/drivers/net/phy/phylink.c > +++ b/drivers/net/phy/phylink.c > @@ -1586,6 +1586,19 @@ 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() > + * > + * Fixed-link mode does not need a PHY, returns a boolean value to check if > + * phylink will be expecting a PHY to attach. > + */ > +bool phylink_expects_phy(struct phylink *pl) > +{ > + return pl->cfg_link_an_mode != MLO_AN_FIXED; > +} > +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);
On Tue, Mar 28, 2023 at 06:57:20PM -0700, Jakub Kicinski wrote: > On Fri, 24 Mar 2023 16:16:54 +0800 Michael Sit Wei Hong 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. > > > > Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> > > Russell, looks good? Not really, given that phylink_attach_phy() will refuse to attach a PHY when: 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; So, if we introduce a helper named "phylink_expects_phy" that returns true when cfg_link_an_mode == MLO_AN_INBAND and the interface mode is e.g. 1000base-X, but then someone tries to attach a PHY, the kernel spits out a warning, backtrace, and a return value of -EINVAL, things are going to look really rather stupid.
> -----Original Message----- > From: Russell King <linux@armlinux.org.uk> > Sent: Wednesday, March 29, 2023 5:01 PM > To: Jakub Kicinski <kuba@kernel.org> > Cc: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com>; > 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>; 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; 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: Re: [PATCH net v3 1/3] net: phylink: add > phylink_expects_phy() method > > On Tue, Mar 28, 2023 at 06:57:20PM -0700, Jakub Kicinski wrote: > > On Fri, 24 Mar 2023 16:16:54 +0800 Michael Sit Wei Hong 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. > > > > > > Signed-off-by: Michael Sit Wei Hong > <michael.wei.hong.sit@intel.com> > > > > Russell, looks good? > > Not really, given that phylink_attach_phy() will refuse to attach a > PHY > when: > > 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; > > So, if we introduce a helper named "phylink_expects_phy" that > returns true when cfg_link_an_mode == MLO_AN_INBAND and the > interface mode is e.g. 1000base-X, but then someone tries to attach > a PHY, the kernel spits out a warning, backtrace, and a return value > of -EINVAL, things are going to look really rather stupid. > Should we check for these 3 conditions as well then? (pl->cfg_link_an_mode == MLO_AN_INBAND && phy_interface_mode_is_8023z(interface) && !pl->sfp_bus) to determine if phylink expects a phy. > -- > RMK's Patch system: > https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Mar 29, 2023 at 09:34:05AM +0000, Sit, Michael Wei Hong wrote: > > > > -----Original Message----- > > From: Russell King <linux@armlinux.org.uk> > > Sent: Wednesday, March 29, 2023 5:01 PM > > To: Jakub Kicinski <kuba@kernel.org> > > Cc: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com>; > > 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>; 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; 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: Re: [PATCH net v3 1/3] net: phylink: add > > phylink_expects_phy() method > > > > On Tue, Mar 28, 2023 at 06:57:20PM -0700, Jakub Kicinski wrote: > > > On Fri, 24 Mar 2023 16:16:54 +0800 Michael Sit Wei Hong 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. > > > > > > > > Signed-off-by: Michael Sit Wei Hong > > <michael.wei.hong.sit@intel.com> > > > > > > Russell, looks good? > > > > Not really, given that phylink_attach_phy() will refuse to attach a > > PHY > > when: > > > > 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; > > > > So, if we introduce a helper named "phylink_expects_phy" that > > returns true when cfg_link_an_mode == MLO_AN_INBAND and the > > interface mode is e.g. 1000base-X, but then someone tries to attach > > a PHY, the kernel spits out a warning, backtrace, and a return value > > of -EINVAL, things are going to look really rather stupid. > > > Should we check for these 3 conditions as well then? > (pl->cfg_link_an_mode == MLO_AN_INBAND && > phy_interface_mode_is_8023z(interface) && !pl->sfp_bus) > to determine if phylink expects a phy. 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. pl->cfg_link_an_mode == MLO_AN_FIXED || (pl->cfg_link_an_mode == MLO_AN_INBAND && phy_interface_mode_is_8023z(interface)) Is true when we're in fixed-link mode, or if we're in in-band mode and using 1000base-X or 25000base-X. These are the conditions that we don't expect the MAC driver to give us a PHY. To put that in positive logic, we expect a PHY from the MAC when we're in PHY mode, or when we're in in-band mode and using SGMII, QSGMII, USXGMII, RGMII, etc. 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.
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 1a2f074685fa..5c2bd1370993 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -1586,6 +1586,19 @@ 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() + * + * Fixed-link mode does not need a PHY, returns a boolean value to check if + * phylink will be expecting a PHY to attach. + */ +bool phylink_expects_phy(struct phylink *pl) +{ + return pl->cfg_link_an_mode != MLO_AN_FIXED; +} +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);