| Message ID | 20200327024552.22170-1-kai.heng.feng@canonical.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | ethtool: Report speed and duplex as unknown when device is runtime suspended | expand |
On 3/26/2020 7:45 PM, Kai-Heng Feng wrote: > Device like igb gets runtime suspended when there's no link partner. We > can't get correct speed under that state: > $ cat /sys/class/net/enp3s0/speed > 1000 > > In addition to that, an error can also be spotted in dmesg: > [ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost > > Since device can only be runtime suspended when there's no link partner, > we can directly report the speed and duplex as unknown. > > Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> > Cc: Aaron Brown <aaron.f.brown@intel.com> > Suggested-by: Alexander Duyck <alexander.duyck@gmail.com> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> I would push this to the responsibility of the various drivers instead of making this part of the standard ethtool implementation.
> On Mar 27, 2020, at 10:56, Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 3/26/2020 7:45 PM, Kai-Heng Feng wrote: >> Device like igb gets runtime suspended when there's no link partner. We >> can't get correct speed under that state: >> $ cat /sys/class/net/enp3s0/speed >> 1000 >> >> In addition to that, an error can also be spotted in dmesg: >> [ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost >> >> Since device can only be runtime suspended when there's no link partner, >> we can directly report the speed and duplex as unknown. >> >> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> >> Cc: Aaron Brown <aaron.f.brown@intel.com> >> Suggested-by: Alexander Duyck <alexander.duyck@gmail.com> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > > I would push this to the responsibility of the various drivers instead > of making this part of the standard ethtool implementation. My original approach [1] is to ask device to runtime resume before calling __ethtool_get_link_ksettings(). Unfortunately it will cause a deadlock if the runtime resume routine wants to hold rtnl_lock. However, it should be totally fine (and sometimes necessary) to be able to hold rtnl_lock in runtime resume routine as Alexander explained [2]. As suggested, this patch handles the situation directly in __ethtool_get_link_ksettings(). [1] https://lore.kernel.org/lkml/20200207101005.4454-2-kai.heng.feng@canonical.com/ [2] https://lkml.org/lkml/2020/3/26/989 Kai-Heng > -- > Florian
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c index 10d929abdf6a..2ba04aa9d775 100644 --- a/net/ethtool/ioctl.c +++ b/net/ethtool/ioctl.c @@ -28,6 +28,7 @@ #include <net/xdp_sock.h> #include <net/flow_offload.h> #include <linux/ethtool_netlink.h> +#include <linux/pm_runtime.h> #include "common.h" @@ -429,6 +430,13 @@ int __ethtool_get_link_ksettings(struct net_device *dev, return -EOPNOTSUPP; memset(link_ksettings, 0, sizeof(*link_ksettings)); + + if (pm_runtime_suspended(dev->dev.parent)) { + link_ksettings->base.duplex = DUPLEX_UNKNOWN; + link_ksettings->base.speed = SPEED_UNKNOWN; + return 0; + } + return dev->ethtool_ops->get_link_ksettings(dev, link_ksettings); } EXPORT_SYMBOL(__ethtool_get_link_ksettings);
Device like igb gets runtime suspended when there's no link partner. We can't get correct speed under that state: $ cat /sys/class/net/enp3s0/speed 1000 In addition to that, an error can also be spotted in dmesg: [ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost Since device can only be runtime suspended when there's no link partner, we can directly report the speed and duplex as unknown. Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Aaron Brown <aaron.f.brown@intel.com> Suggested-by: Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> --- net/ethtool/ioctl.c | 8 ++++++++ 1 file changed, 8 insertions(+)