netdev - Re: [PATCH net-next] net: Set device operstate at registration time

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: <20120824.124815.1292475998883382478.davem@davemloft.net>
Date:	Fri, 24 Aug 2012 12:48:15 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	netdev@...r.kernel.org, shemminger@...tta.com,
	shchepetkov@...ras.ru, bjorn@...k.no, mike@...ineau.org
Subject: Re: [PATCH net-next] net: Set device operstate at registration time

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Mon, 20 Aug 2012 22:16:51 +0100

> This initialises the operstate synchronously at registration time
> only.

Ok, this looks good to me, applied.  Thanks Ben.

> This seems to deal properly with the registration-time problem, but not
> the case where a device is brought down and then up again.  Many but not
> all drivers that support carrier detection call netif_carrier_off() in
> their ndo_stop method.  Should the others be changed, or is there some
> way we can make that automatic?

There are several cases.

For example, if the device does not power down the PHY over stop/start
it should leave the carrier state alone.  This is the case for every
NIC that runs management firmware, which therefore needs the link to
stay up even when the NIC is administratively brought down.

If it does power down the PHY, that netif_carrier_off() call should
already be contained in the PHY powerdown code.
--
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