[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A480FA8.4000401@miraclelinux.com>
Date: Mon, 29 Jun 2009 09:49:44 +0900
From: Naohiro Ooiwa <nooiwa@...aclelinux.com>
To: Michael Chan <mchan@...adcom.com>
CC: Rick Jones <rick.jones2@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] bnx2: Fix the behavior of ethtool when ONBOOT=no
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 <nooiwa@...aclelinux.com>
---
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.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists