From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B648C7619A for ; Wed, 5 Apr 2023 10:18:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237574AbjDEKSt (ORCPT ); Wed, 5 Apr 2023 06:18:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237291AbjDEKSs (ORCPT ); Wed, 5 Apr 2023 06:18:48 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBF7C4C27; Wed, 5 Apr 2023 03:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yJ16+cUT0D7ZVTErfZwxzpUUZnFQ1yqnqpQx3pT2yuE=; b=xNXdVbtPEQ7P54mUHFZ1T4HKNB ukQx0seAcml+qIAsJ2sLzXRsiPchyuM64rLCzMlXxHsQDJRIubi+34vv2ToTtIK3iZ/ATyjSda7nf Oi2DuJUcczk+WMWnVT2qwWkyJD3QAXEK2xlyRuNt22/NHyFnwsMVRkYyGSyMIgd9gNQ3W/xQFbSBS 04x9A54r2+piVmdAQxWvxOwSDHWjBFCypmkT7M8k2rGFTEQ/rckQKkDwrzYNKZxeF8zX3o/ab0/Lg g2z8YmB1ZKNG43Y+0bFl7O0drdS8B3229jr1dcUD+kvN3Fd9mJ+V2VRBvVKwteoplvcd9FyB1jD+u UQlBk+rA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:56198) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pk0Db-0005KI-EB; Wed, 05 Apr 2023 11:18:19 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pk0DW-0006DJ-CA; Wed, 05 Apr 2023 11:18:14 +0100 Date: Wed, 5 Apr 2023 11:18:14 +0100 From: "Russell King (Oracle)" To: Michael Sit Wei Hong Cc: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Ong Boon Leong , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, hkallweit1@gmail.com, andrew@lunn.ch, Martin Blumenstingl , Shahab Vahedi , Marek Szyprowski , Looi Hong Aun , Voon Weifeng , Lai Peter Jun Ann , Zulkifli Muhammad Husaini , Tan Tee Min , hock.leong.kweh@intel.com Subject: Re: [PATCH net 1/1] net: stmmac: check fwnode for phy device before scanning for phy Message-ID: References: <20230405093945.3549491-1-michael.wei.hong.sit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230405093945.3549491-1-michael.wei.hong.sit@intel.com> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Apr 05, 2023 at 05:39:45PM +0800, Michael Sit Wei Hong wrote: > Some DT devices already have phy device configured in the DT/ACPI. > Current implementation scans for a phy unconditionally even though > there is a phy listed in the DT/ACPI and already attached. > > We should check the fwnode if there is any phy device listed in > fwnode and decide whether to scan for a phy to attach to.y > > Reported-by: Martin Blumenstingl Suggested-by: Russell King (Oracle) > Fixes: fe2cfbc96803 ("net: stmmac: check if MAC needs to attach to a PHY") > Signed-off-by: Michael Sit Wei Hong > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index d41a5f92aee7..7ca9be7bec06 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -1134,22 +1134,26 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv) > static int stmmac_init_phy(struct net_device *dev) > { > struct stmmac_priv *priv = netdev_priv(dev); > + struct fwnode_handle *phy_fwnode; > struct fwnode_handle *fwnode; > - bool phy_needed; > int ret; > > + if (!phylink_expects_phy(priv->phylink)) > + return 0; > + > fwnode = of_fwnode_handle(priv->plat->phylink_node); > if (!fwnode) > fwnode = dev_fwnode(priv->device); > > if (fwnode) > - ret = phylink_fwnode_phy_connect(priv->phylink, fwnode, 0); > + phy_fwnode = fwnode_get_phy_node(fwnode); > + else > + phy_fwnode = NULL; > > - phy_needed = phylink_expects_phy(priv->phylink); > /* Some DT bindings do not set-up the PHY handle. Let's try to > * manually parse it > */ > - if (!fwnode || phy_needed || ret) { > + if (!phy_fwnode || IS_ERR(phy_fwnode)) { > int addr = priv->plat->phy_addr; > struct phy_device *phydev; > > @@ -1165,6 +1169,9 @@ static int stmmac_init_phy(struct net_device *dev) > } > > ret = phylink_connect_phy(priv->phylink, phydev); > + } else { > + fwnode_handle_put(phy_fwnode); > + ret = phylink_fwnode_phy_connect(priv->phylink, fwnode, 0); > } > > if (!priv->plat->pmt) { LGTM, thanks for taking on board my suggestion. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!