Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Hao Chen <chenhaoa@uniontech.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: [net,v7] net: stmmac: fix 'ethtool -P' return -EBUSY
Date: Sat, 31 Jul 2021 11:35:58 +0200	[thread overview]
Message-ID: <8d1b5896-da9f-954f-6d43-061b75863961@gmail.com> (raw)
In-Reply-To: <20210731050928.32242-1-chenhaoa@uniontech.com>

On 31.07.2021 07:09, Hao Chen wrote:
> I want to get permanent MAC address when the card is down. And I think
"card is down" isn't precise. The interface is down, and the NIC may be
runtime-suspended.

> it is more convenient to get statistics in the down state by 'ethtool -S'.
> But current all of the ethool command return -EBUSY.
> 
> I don't think we should detect that the network card is up in '. Begin',

You don't mean detect but check here.

> which will cause that all the ethtool commands can't be used when the
> network card is down. If some ethtool commands can only be used in the
> up state, check it in the corresponding ethool OPS function is better.
> This is too rude and unreasonable.
> 
> I have checked the '.begin' implementation of other drivers, most of which
> support the submission of NIC driver for the first time.

What do you mean with "submission for the first time"?

> They are too old to know why '.begin' is implemented. I suspect that they
> have not noticed the usage of '.begin'.
> 
> Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet
> 		     controllers.")
> 

IMO it's not a bug that ethtool calls aren't supported if interface is
down. Therefore personally I'd see this for net-next. Final call is with
the maintainers.

> Compile-tested on arm64. Tested on an arm64 system with an on-board
> STMMAC chip.
> 
> Changes v6 ... v7:
> - fix arg type error of 'dev' to 'priv->device'.
> 
> Changes v5 ... v6:
> - The 4.19.90 kernel not support pm_runtime, so implemente '.begin' and
>   '.complete' again. Add return value check of pm_runtime function.
> 
> Changes v4 ... v5:
> - test the '.begin' will return -13 error on my machine based on 4.19.90
>   kernel. The platform driver does not supported pm_runtime. So remove the
>   implementation of '.begin' and '.complete'.
> 
> Changes v3 ... v4:
> - implement '.complete' ethtool OPS.
> 
> Changes v2 ... v3:
> - add linux/pm_runtime.h head file.
> 
> Changes v1 ... v2:
> - fix spell error of dev.
> 
> Signed-off-by: Hao Chen <chenhaoa@uniontech.com>
> ---
>  .../ethernet/stmicro/stmmac/stmmac_ethtool.c  | 21 +++++++++++++------
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index d0ce608b81c3..fd5b68f6bf53 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -12,8 +12,9 @@
>  #include <linux/ethtool.h>
>  #include <linux/interrupt.h>
>  #include <linux/mii.h>
> -#include <linux/phylink.h>

Why moving the phylink include?

>  #include <linux/net_tstamp.h>
> +#include <linux/phylink.h>
> +#include <linux/pm_runtime.h>
>  #include <asm/io.h>
>  
>  #include "stmmac.h"
> @@ -410,11 +411,18 @@ static void stmmac_ethtool_setmsglevel(struct net_device *dev, u32 level)
>  
>  }
>  
> -static int stmmac_check_if_running(struct net_device *dev)
> +static int stmmac_ethtool_begin(struct net_device *dev)
>  {
> -	if (!netif_running(dev))
> -		return -EBUSY;
> -	return 0;
> +	struct stmmac_priv *priv = netdev_priv(dev);

Power-managed is the parent of the net_device.
So you could simply use dev->dev.parent.

> +
> +	return pm_runtime_resume_and_get(priv->device);
> +}
> +
> +static void stmmac_ethtool_complete(struct net_device *dev)
> +{
> +	struct stmmac_priv *priv = netdev_priv(dev);
> +
> +	pm_runtime_put(priv->device);
>  }
>  
>  static int stmmac_ethtool_get_regs_len(struct net_device *dev)
> @@ -1073,7 +1081,8 @@ static int stmmac_set_tunable(struct net_device *dev,
>  static const struct ethtool_ops stmmac_ethtool_ops = {
>  	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
>  				     ETHTOOL_COALESCE_MAX_FRAMES,
> -	.begin = stmmac_check_if_running,
> +	.begin = stmmac_ethtool_begin,
> +	.complete = stmmac_ethtool_complete,
>  	.get_drvinfo = stmmac_ethtool_getdrvinfo,
>  	.get_msglevel = stmmac_ethtool_getmsglevel,
>  	.set_msglevel = stmmac_ethtool_setmsglevel,
> 

You sent this patch to the mailing list only and missed to address the
maintainers.

I think the question whether an ethtool call should wake a network device
from runtime suspend is a general one (at least for all network drivers
with runtime pm support) and not restricted to stmmac. 
Strictly needed is waking the device only if e.g. a chip register is
accessed that isn't available during runtime-suspend. However personally
I'd be fine with the small overhead of always waking the device.

If there's an agreement that this makes sense in general then we may add
this to core code, by e.g. runtime-resuming netdev->dev.parent (and maybe
netdev->dev if netdev has no parent).

  reply	other threads:[~2021-07-31  9:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31  5:09 Hao Chen
2021-07-31  9:35 ` Heiner Kallweit [this message]
2021-07-31 16:23   ` Jakub Kicinski
2021-08-01 10:22     ` Heiner Kallweit
     [not found] <20210722015433.8563-1-chenhaoa@uniontech.com>
     [not found] ` <6015f3a3-1e6e-5242-bc2b-32d3b077d0e8@uniontech.com>
2021-07-30 11:23   ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d1b5896-da9f-954f-6d43-061b75863961@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=chenhaoa@uniontech.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --subject='Re: [net,v7] net: stmmac: fix '\''ethtool -P'\'' return -EBUSY' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).