Re: [PATCH] bnx2: Fix the behavior of ethtool when ONBOOT=no
From: Naohiro Ooiwa <hidden>
Date: 2009-06-29 00:49:43
Subsystem:
networking drivers, the rest · Maintainers:
Andrew Lunn, "David S. Miller", Eric Dumazet, Jakub Kicinski, Paolo Abeni, Linus Torvalds
Hi Michael Thank you for your comment. I tried to create a patch of bnx2x driver. It's the same fix as bnx2 driver. Could you please check the my patch ? Of cource, I made sure of compile. Best Regards, Naohiro Ooiwa Signed-off-by: Naohiro Ooiwa <redacted> --- drivers/net/bnx2x_main.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index fbf1352..951714a 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c@@ -8637,6 +8637,14 @@ static int bnx2x_nway_reset(struct net_device *dev) return 0; } +static u32 +bnx2x_get_link(struct net_device *dev) +{ + struct bnx2x *bp = netdev_priv(dev); + + return bp->link_vars.link_up; +} + static int bnx2x_get_eeprom_len(struct net_device *dev) { struct bnx2x *bp = netdev_priv(dev);
@@ -10034,7 +10042,7 @@ static struct ethtool_ops bnx2x_ethtool_ops = { .get_msglevel = bnx2x_get_msglevel, .set_msglevel = bnx2x_set_msglevel, .nway_reset = bnx2x_nway_reset, - .get_link = ethtool_op_get_link, + .get_link = bnx2x_get_link, .get_eeprom_len = bnx2x_get_eeprom_len, .get_eeprom = bnx2x_get_eeprom, .set_eeprom = bnx2x_set_eeprom,
--
1.5.4.1
Michael Chan wrote:
> On Wed, 2009-06-24 at 09:43 -0700, Rick Jones wrote:
>> Naohiro Ooiwa wrote:
>>> Hi Michael
>>>
>>> I found a little bug.
>>>
>>> When configure in ifcfg-eth* is ONBOOT=no,
>>> the behavior of ethtool command is wrong.
>>>
>>> # grep ONBOOT /etc/sysconfig/network-scripts/ifcfg-eth2
>>> ONBOOT=no
>>> # ethtool eth2 | tail -n1
>>> Link detected: yes
>>>
>>> I think "Link detected" should be "no".
>> Why? Sure, there is no IP on the link, but does that mean the link is
>> otherwise unusable? Is ethtool only about IP status?
>>
>
> Once the device is closed, we no longer keep track of the link state and
> no longer have register access to determine the link state. So we
> assume it is down. In reality, it may still be up if WoL is enabled or
> management firmware is running, but the driver can no longer keep track
> of it. If we have to assume one or the other, I think it is more
> correct to assume it is down.
>
>
>