lkml.org 
[lkml]   [2020]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ethtool: Report speed and duplex as unknown when device is runtime suspended
From
Date


> 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

\
 
 \ /
  Last update: 2020-03-27 04:12    [W:0.044 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site