Message ID | 20230130080714.139492-16-o.rempel@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2061842wrn; Mon, 30 Jan 2023 00:08:36 -0800 (PST) X-Google-Smtp-Source: AMrXdXvvbZELw9L0X02jRMQrk/fUqSTLYwwOsqx/jlcStNqoDtHAwstLc1JqhTIhDIPI+3B4wFuc X-Received: by 2002:a50:ff17:0:b0:499:d208:e8f4 with SMTP id a23-20020a50ff17000000b00499d208e8f4mr50379895edu.19.1675066116150; Mon, 30 Jan 2023 00:08:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675066116; cv=none; d=google.com; s=arc-20160816; b=LXRPKR+i29t7Lcheawt+IT55MjviKCwHF6llqOAv64WHQJwTay3NBr0Gk3NUoXTtDZ UX7gdHsrZgRS+U+5CS41x+Hl4BfsUl4HSpfPt1MWxlMYWiN4KhEuT5hOpA2REnx/2kMs tK5PkF0B9h6lcpcHY7rOhQcLdNEkT7h0uYPUlSOpWDN1uu8W0rkS0NNIqGp3ZWsa13ep 383QugEgQ90/RdjEM3Rf034gu5lrqFHL/msxjfHAnKVjgT7FP7oXd0jl9Nu0t3BvdAO9 JwD4QlG+LwVfL2aanHBVJQRCnUZIa/DyiIZv5IjbylC2zuGU1cfdFo8dSWvgC1lqlrSH SJ+g== 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; bh=iO07/urYCL9jILjUKaMGfbd9c6V/E+eIHFfF4aj4hVg=; b=RwL0K8Idv5t2lvKLla+PHhPk2Tzoo9pFE8VZ9mE7gVkEzc1GqVfk7TeF4vUaI7GSRg F0Fh59ZYe9NuzhnYrpsEm+8n5eLThv85qZqyJ3a1cwbcUuxZTZk2vqXXicAl9l+vVXHO rE2xnrXMZWEiQlQYYte06bQaGZu06TF0GR6S5f6e9roqQz45c1OgeLSvIN9F5Eh7P/wI D8v3BL+UIZlcFmOSD+OpCU/QlOWpZDV+/+1LRrPPYUytQawOIwO2mpr20iJqKiLxGvM4 6OYCfwdgNiWihxtIpqkph+F9rFjOEmKataLZR5DtlaHCsjiH0qZHGS47b7b7EUZJd4n1 svhA== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eo10-20020a056402530a00b004a2359ecff1si4515737edb.264.2023.01.30.00.08.11; Mon, 30 Jan 2023 00:08:36 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235769AbjA3IHu (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Mon, 30 Jan 2023 03:07:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235579AbjA3IHc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Jan 2023 03:07:32 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDA4D298CB for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 00:07:29 -0800 (PST) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ore@pengutronix.de>) id 1pMPCB-0003fD-2h; Mon, 30 Jan 2023 09:07:19 +0100 Received: from [2a0a:edc0:0:1101:1d::ac] (helo=dude04.red.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from <ore@pengutronix.de>) id 1pMPCA-001PwJ-TS; Mon, 30 Jan 2023 09:07:18 +0100 Received: from ore by dude04.red.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from <ore@pengutronix.de>) id 1pMPC7-000aLB-PN; Mon, 30 Jan 2023 09:07:15 +0100 From: Oleksij Rempel <o.rempel@pengutronix.de> To: Woojung Huh <woojung.huh@microchip.com>, UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>, Vivien Didelot <vivien.didelot@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de>, kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Arun.Ramadoss@microchip.com Subject: [PATCH net-next v3 15/15] net: fec: add support for PHYs with SmartEEE support Date: Mon, 30 Jan 2023 09:07:14 +0100 Message-Id: <20230130080714.139492-16-o.rempel@pengutronix.de> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230130080714.139492-1-o.rempel@pengutronix.de> References: <20230130080714.139492-1-o.rempel@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756434128097561186?= X-GMAIL-MSGID: =?utf-8?q?1756434128097561186?= |
Series |
net: add EEE support for KSZ9477 and AR8035 with i.MX6
|
|
Commit Message
Oleksij Rempel
Jan. 30, 2023, 8:07 a.m. UTC
Ethernet controller in i.MX6*/i.MX7* series do not provide EEE support.
But this chips are used sometimes in combinations with SmartEEE capable
PHYs.
So, instead of aborting get/set_eee access on MACs without EEE support,
ask PHY if it is able to do the EEE job by using SmartEEE.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/net/ethernet/freescale/fec_main.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
Comments
On Mon, Jan 30, 2023 at 09:07:14AM +0100, Oleksij Rempel wrote: > Ethernet controller in i.MX6*/i.MX7* series do not provide EEE support. > But this chips are used sometimes in combinations with SmartEEE capable > PHYs. > So, instead of aborting get/set_eee access on MACs without EEE support, > ask PHY if it is able to do the EEE job by using SmartEEE. > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> > --- > drivers/net/ethernet/freescale/fec_main.c | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c > index e6238e53940d..25a2a9d860de 100644 > --- a/drivers/net/ethernet/freescale/fec_main.c > +++ b/drivers/net/ethernet/freescale/fec_main.c > @@ -3102,8 +3102,15 @@ fec_enet_get_eee(struct net_device *ndev, struct ethtool_eee *edata) > struct fec_enet_private *fep = netdev_priv(ndev); > struct ethtool_eee *p = &fep->eee; > > - if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) > - return -EOPNOTSUPP; > + if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) { > + if (!netif_running(ndev)) > + return -ENETDOWN; > + > + if (!phy_has_smarteee(ndev->phydev)) > + return -EOPNOTSUPP; > + > + return phy_ethtool_get_eee(ndev->phydev, edata); I see many places in the fec driver guarding against a NULL ndev->phydev, and TBH I don't completely understand why. I guess it's because ndev->phydev is populated at fec_enet_open() time. But then again, if the netif_running() check is sufficient to imply presence of ndev->phydev as you suggest, then why does fec_enet_ioctl() have this? if (!netif_running(ndev)) return -EINVAL; if (!phydev) return -ENODEV; Asking because phy_init_eee(), phy_ethtool_set_eee() and phy_ethtool_get_eee() don't support being called with a NULL phydev.
On Tue, Jan 31, 2023 at 10:52:31PM +0200, Vladimir Oltean wrote: > On Mon, Jan 30, 2023 at 09:07:14AM +0100, Oleksij Rempel wrote: > > Ethernet controller in i.MX6*/i.MX7* series do not provide EEE support. > > But this chips are used sometimes in combinations with SmartEEE capable > > PHYs. > > So, instead of aborting get/set_eee access on MACs without EEE support, > > ask PHY if it is able to do the EEE job by using SmartEEE. > > > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> > > --- > > drivers/net/ethernet/freescale/fec_main.c | 22 ++++++++++++++++++---- > > 1 file changed, 18 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c > > index e6238e53940d..25a2a9d860de 100644 > > --- a/drivers/net/ethernet/freescale/fec_main.c > > +++ b/drivers/net/ethernet/freescale/fec_main.c > > @@ -3102,8 +3102,15 @@ fec_enet_get_eee(struct net_device *ndev, struct ethtool_eee *edata) > > struct fec_enet_private *fep = netdev_priv(ndev); > > struct ethtool_eee *p = &fep->eee; > > > > - if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) > > - return -EOPNOTSUPP; > > + if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) { > > + if (!netif_running(ndev)) > > + return -ENETDOWN; > > + > > + if (!phy_has_smarteee(ndev->phydev)) > > + return -EOPNOTSUPP; > > + > > + return phy_ethtool_get_eee(ndev->phydev, edata); > > I see many places in the fec driver guarding against a NULL > ndev->phydev, and TBH I don't completely understand why. > I guess it's because ndev->phydev is populated at fec_enet_open() time. > > But then again, if the netif_running() check is sufficient to imply > presence of ndev->phydev as you suggest, then why does fec_enet_ioctl() > have this? > > if (!netif_running(ndev)) > return -EINVAL; > > if (!phydev) > return -ENODEV; > > Asking because phy_init_eee(), phy_ethtool_set_eee() and > phy_ethtool_get_eee() don't support being called with a NULL phydev. Hm.. phy_start() is protected against NULL phydev and it is used in fec_enet_open(). Right now i do not know what is better way go. Any preferences? Regards, Oleksij
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index e6238e53940d..25a2a9d860de 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3102,8 +3102,15 @@ fec_enet_get_eee(struct net_device *ndev, struct ethtool_eee *edata) struct fec_enet_private *fep = netdev_priv(ndev); struct ethtool_eee *p = &fep->eee; - if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) - return -EOPNOTSUPP; + if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) { + if (!netif_running(ndev)) + return -ENETDOWN; + + if (!phy_has_smarteee(ndev->phydev)) + return -EOPNOTSUPP; + + return phy_ethtool_get_eee(ndev->phydev, edata); + } if (!netif_running(ndev)) return -ENETDOWN; @@ -3123,8 +3130,15 @@ fec_enet_set_eee(struct net_device *ndev, struct ethtool_eee *edata) struct ethtool_eee *p = &fep->eee; int ret = 0; - if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) - return -EOPNOTSUPP; + if (!(fep->quirks & FEC_QUIRK_HAS_EEE)) { + if (!netif_running(ndev)) + return -ENETDOWN; + + if (!phy_has_smarteee(ndev->phydev)) + return -EOPNOTSUPP; + + return phy_ethtool_set_eee(ndev->phydev, edata); + } if (!netif_running(ndev)) return -ENETDOWN;