linux-kernel - Re: Network drivers that don't suspend on interface down

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: <20061221011209.GA32625@srcf.ucam.org>
Date:	Thu, 21 Dec 2006 01:12:09 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down

On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote:

> 	When device is down, it should:
> 	 a) use as few resources as possible:
> 	       - not grab memory for buffers
> 	       - not assign IRQ unless it could get one
> 	       - turn off all power consumption possible
> 	 b) allow setting parameters like speed/duplex/autonegotiation,
>             ring buffers, ... with ethtool, and remember the state

Veering off at something of a tangent - how much of this should be true 
for wireless devices? Softmac seems to be unhappy about setting the 
essid unless the card is up, which breaks various assumptions...

Beyond that, I think your descriptions of up and down states make sense 
for userspace. As Arjan suggests, there's then the intermediate state of 
"disable as much as possible while still providing scanning and link 
detection".

> 2) Network device infrastructure should make it easier for devices:
>     bring interface down on suspend and bring it up after resume
>     (if it was running when suspended). This would allow many devices to
>     have no suspend/resume hook; except those that have some better power
>     control over hardware.

I'd have some concerns over how that would interact with the rest of the 
PM infrastructure, but it certainly sounds good in principle.

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/