netdev - Re: [PATCH] drivers/net: Call netif_carrier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1297785532.2584.10.camel@bwh-desktop>
Date:	Tue, 15 Feb 2011 15:58:52 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org,
	davem@...emloft.net, aabdulla@...dia.com,
	Ben Hutchings <ben@...adent.org.uk>
Subject: Re: [PATCH] drivers/net: Call netif_carrier_off at the end of the
 probe

On Tue, 2011-02-15 at 16:22 +0100, Francois Romieu wrote:
> Ivan Vecera <ivecera@...hat.com> :
> > Without calling of netif_carrier_off at the end of the probe the operstate
> > is unknown when the device is initially opened. By default the carrier is
> > on so when the device is opened and netif_carrier_on is called the link
> > watch event is not fired and operstate remains zero (unknown).
> 
> Stated this way it sounds like a core dev layer issue.

Due to hardware limitations, some network drivers cannot report the
carrier state and they never call netif_carrier_{on,off}().  Therefore
the initial operstate of 'unknown' is correct.

> I am not completely sure after reading some history. Namely:
> - (37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71 ?)
> - c276e098d3ee33059b4a1c747354226cec58487c 
> - 22604c866889c4b2e12b73cbf1683bda1b72a313
> - b47300168e770b60ab96c8924854c3b0eb4260eb
> 
> I am confused.

Drivers that can report carrier state should do so initially some time
between registering a device and bringing it up (either in the bus probe
function or the ndo_open function).  It generally seems to be safe to
assume that the link is down initially, and then to rely on
notifications from the hardware.  However, that does depend on the
behaviour of the hardware.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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