From mboxrd@z Thu Jan 1 00:00:00 1970 From: Naohiro Ooiwa Subject: Re: [PATCH] bnx2: Fix the behavior of ethtool when ONBOOT=no Date: Fri, 26 Jun 2009 13:30:51 +0900 Message-ID: <4A444EFB.3010702@miraclelinux.com> References: <20090624.164233.166634429.davem@davemloft.net> <1245887312.12000.543.camel@nseg_linux_HP1.broadcom.com> <20090624.171246.236728523.davem@davemloft.net> <20090624.172544.67048473.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mchan@broadcom.com, rick.jones2@hp.com, netdev@vger.kernel.org To: David Miller Return-path: Received: from mailgw.miraclelinux.com ([122.216.84.157]:49184 "EHLO mailgw.miraclelinux.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbZFZEav (ORCPT ); Fri, 26 Jun 2009 00:30:51 -0400 In-Reply-To: <20090624.172544.67048473.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: Hi David Thank you for taking a look at the NM sources. FYI, I confirmed the behavior of e1000e driver. The condition is ONBOOT=no, and with or without LAN cable. bnx2 is included this patch. | LAN cable | ethtool | | Link detected -------+-----------+---------------- e1000e | plugged | yes e1000e | unplugged | no bnx2 | plugged | yes bnx2 | unplugged | no (previously "yes") The behavior of bnx2 became congruent with e1000e. The looks is natural for me. Best Regards, Naohiro Ooiwa David Miller wrote: > From: David Miller > Date: Wed, 24 Jun 2009 17:12:46 -0700 (PDT) > >> From: "Michael Chan" >> Date: Wed, 24 Jun 2009 16:48:32 -0700 >> >>> I don't know about NetworkManager, but the old ifup script will bring up >>> the device, wait up to 5 seconds for link up, and then do DHCP. >> I'll swallow a handful of antacid tablets and take a look at >> the NM sources :-/ > > Ok, NM first checks if the device supports either ethtool or > MII based link status. > > It checks for these capabilities by openning the device, trying > the ethtool/ioctl op, then closing the device. > > If link status reporting is found to be supported, it records the > initial link state and listens for netlink events. (these are > generated by netif_carrier_{on,off}() calls in the kernel) > > When a link-up status netlink event is received, it brings wired > devices reporting such events up. > > And most importantly, it seems to bring the device UP during all > of this stuff. > > So I guess we're OK. >