Message-ID: <DB8PR04MB6795C17FB0FEAD38F749EAFDE6E39@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date:   Wed, 21 Jul 2021 03:02:27 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Hao Chen <chenhaoa@...ontech.com>,
        Heiner Kallweit <hkallweit1@...il.com>
CC:     "alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
        "joabreu@...opsys.com" <joabreu@...opsys.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>
Subject: RE: [PATCH v5] net: stmmac: fix 'ethtool -P' return -EBUSY


> -----Original Message-----
> From: Hao Chen <chenhaoa@...ontech.com>
> Sent: 2021年7月21日 9:35
> To: Heiner Kallweit <hkallweit1@...il.com>
> Cc: alexandre.torgue@...s.st.com; joabreu@...opsys.com;
> davem@...emloft.net; kuba@...nel.org; mcoquelin.stm32@...il.com;
> linux@...linux.org.uk; netdev@...r.kernel.org;
> linux-stm32@...md-mailman.stormreply.com; Joakim Zhang
> <qiangqing.zhang@....com>; peppe.cavallaro@...com
> Subject: Re: [PATCH v5] net: stmmac: fix 'ethtool -P' return -EBUSY
> 
> 
> 在 2021/7/19 下午9:57, Heiner Kallweit 写道:
> > On 19.07.2021 15:08, Hao Chen wrote:
> >> The permanent mac address should be available for query when the
> >> device is not up.
> >> NetworkManager, the system network daemon, uses 'ethtool -P' to
> >> obtain the permanent address after the kernel start. When the network
> >> device is not up, it will return the device busy error with 'ethtool
> >> -P'. At that time, it is unable to access the Internet through the
> >> permanent address by NetworkManager.
> > At first a few formal aspects:
> > - You don't get a lot of new friends when posting a new version every
> >    few hours. Consolidate feedback and then post a new version,
> >    typically not more than one version per day. Mileage of maintainers
> >    may vary here.
> > - When posting a new version include a change log.
> > - Properly annotate the patch as net vs. net-next.
> > - If you declare something to be a fix, add a Fixes tag.
> Thanks for your guidance.
> >> I think that the '.begin' is not used to check if the device is up,
> >> it's just a pre hook for ethtool. We shouldn't check if the device is
> >> up there.
> >>
> > Supposedly the check is there for a reason. Your statement leaves the
> > impression that you're not aware of why the check exists.
> > Therefore: First understand this, and then explain why it's safe to
> > remove the check. This drivers uses runtime pm, so device might be in
> > PCI D3 if interface is down (don't know this driver in detail).
> > Therefore registers may not be accessible what may impact certain
> > ethtool ops.
> 
> The network manager obtains and stores the permanent MAC address before
> the network
> 
> card is up, and then the user can specify the MAC address of the device in the
> desktop network
> 
> manager for networking.
> 
> 
> If the driver needs the network card up to obtain the permanent MAC address,
> the user will
> 
> not be able to specify the device MAC address for networking after power on.

I'm not sure quite understand what's your requirements, AFAIK, NIC driver has
.ndo_set_mac_address to set mac address, and it can be done whether ifup or ifdown.

> 
> I don't think we should detect that the network card is up in '. Begin', 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, they should be detected in the
> corresponding
> 
> ethool OPS function instead of in the pre hook. This is too rude and
> unreasonable.
> 
> 
> As for safe, remove the '. Begin' implementation. After modification, it
> should be safer to
> 
> operate Ethernet in the down state than in the up state.

As Heiner mentioned, ethtool ops may access NIC hardware registers which need
clocks enabled. Now we have .begin that means clocks enabled when use ethtool,
if you remove .begin, you need ensure clocks enabled whenever ethtool used. So,
remove .begin directly wound not be acceptable.

> 
> I have checked the '. Begin' implementation of other drivers, most of
> which support the
> 
> submission of NIC driver for the first time. They are too long to know
> why '. Begin' is
> 
> implemented. I suspect that they have not noticed the usage of '. Begin'.
> 
> In cpsw NIC driver, commit ID 7898b1daf0555, a bug was found to be fixed:
> 
> "The CPSW might be suspended by RPM if all ethX interfaces are down,
> 
> but it still could be accesible through ethtool interfce. In this case
> ethtool operations, requiring registers access, will cause L3 errors and
> CPSW crash."
> 
> My machine uses platform GMAC. I don't have PCI network card. I can't
> test the use
> 
> of PCI network card. Through cat /sys/devices/... /power/
> runtime_status, return
> 
> unsupported. Therefore, runtime PM is not supported.

I have a GMAC5.10 at my hand, and check the runtime PM status on net-next tree:
~# cat /sys/class/net/eth0/device/power/runtime_status
Active

Another main you said:
"By browse the code and test it,  I find that stmmac not support runtime_status,

pm_runtime_get_sync will return -13 errno. So shouldn't modify it in this way.

I think we should just delete the implementation of begin, it's a pre hook for ethtool."

I don't know why " pm_runtime_get_sync will return -13 errno ". If so, STMMAC driver still
can work at you side? Clocks always enabled after probed?

Best Regards,
Joakim Zhang
> 
> To sum up, I think it's better to remove the '. Begin' implementation here.
> 
> Or use the following implementation:
> 
>    static int stmmac_ethtool_begin(struct net_device *dev)
> {
>            struct stmmac_priv *priv = netdev_priv(dev);
>            int ret;
> 
>            if (strcmp(priv->device->bus_type->name, "pci"))
>                    return 0;
> 
>            return pm_runtime_resume_and_get(dev);
> }
> 
>    static void stmmac_ethtool_complete(struct net_device *dev)
> {
>            struct stmmac_priv *priv = netdev_priv(dev);
> 
>            if (strcmp(priv->device->bus_type->name, "pci"))
> return;
> 
> pm_runtime_put(priv->device);
>    }
> 
>   .begin = stmmac_ethtool_begin,
>   .complete = stmmac_ethtool_complete,
> >> Signed-off-by: Hao Chen <chenhaoa@...ontech.com>
> >> ---
> >>   drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 8 --------
> >>   1 file changed, 8 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> >> index d0ce608b81c3..8901dc9f758e 100644
> >> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> >> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> >> @@ -410,13 +410,6 @@ static void stmmac_ethtool_setmsglevel(struct
> net_device *dev, u32 level)
> >>
> >>   }
> >>
> >> -static int stmmac_check_if_running(struct net_device *dev)
> >> -{
> >> -	if (!netif_running(dev))
> >> -		return -EBUSY;
> >> -	return 0;
> >> -}
> >> -
> >>   static int stmmac_ethtool_get_regs_len(struct net_device *dev)
> >>   {
> >>   	struct stmmac_priv *priv = netdev_priv(dev);
> >> @@ -1073,7 +1066,6 @@ 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,
> >>   	.get_drvinfo = stmmac_ethtool_getdrvinfo,
> >>   	.get_msglevel = stmmac_ethtool_getmsglevel,
> >>   	.set_msglevel = stmmac_ethtool_setmsglevel,
> >>
> >

Powered by blists - more mailing lists