From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: Network drivers that don't suspend on interface down
Date: Thu, 21 Dec 2006 01:12:09 +0000 [thread overview]
Message-ID: <20061221011209.GA32625@srcf.ucam.org> (raw)
In-Reply-To: <20061220144906.7863bcd3@dxpl.pdx.osdl.net>
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@srcf.ucam.org
next prev parent reply other threads:[~2006-12-21 1:12 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061219185223.GA13256@srcf.ucam.org>
[not found] ` <200612191959.43019.david-b@pacbell.net>
[not found] ` <20061220042648.GA19814@srcf.ucam.org>
[not found] ` <200612192114.49920.david-b@pacbell.net>
[not found] ` <20061220053417.GA29877@suse.de>
[not found] ` <20061220055209.GA20483@srcf.ucam.org>
[not found] ` <1166601025.3365.1345.camel@laptopd505.fenrus.org>
2006-12-20 12:53 ` Network drivers that don't suspend on interface down Matthew Garrett
2006-12-20 13:38 ` Arjan van de Ven
2006-12-20 14:31 ` Matthew Garrett
2006-12-20 15:51 ` Arjan van de Ven
2006-12-20 22:49 ` Stephen Hemminger
2006-12-20 23:37 ` Rick Jones
2006-12-19 23:51 ` Stephen Hemminger
2006-12-21 0:11 ` Francois Romieu
2006-12-20 0:26 ` Stephen Hemminger
2006-12-21 11:18 ` Francois Romieu
2006-12-21 1:12 ` Matthew Garrett [this message]
2006-12-21 2:05 ` Michael Wu
2006-12-21 2:18 ` Matthew Garrett
2006-12-21 2:38 ` Daniel Drake
2006-12-21 2:45 ` Matthew Garrett
2006-12-21 3:08 ` Daniel Drake
2006-12-21 3:25 ` Matthew Garrett
2006-12-21 3:37 ` Dan Williams
2006-12-21 3:29 ` Dan Williams
2006-12-21 3:14 ` Dan Williams
2006-12-21 13:14 ` jamal
2006-12-21 2:29 ` Daniel Drake
2006-12-21 2:10 ` Jesse Brandeburg
2006-12-21 8:54 ` Arjan van de Ven
2006-12-22 1:03 ` Herbert Xu
2006-12-23 8:54 ` Pavel Machek
2006-12-20 15:27 ` Olivier Galibert
2006-12-20 15:34 ` Arjan van de Ven
2006-12-20 16:40 ` Olivier Galibert
2006-12-20 17:21 ` Arjan van de Ven
2006-12-20 20:40 ` Benny Amorsen
2006-12-20 21:49 ` Arjan van de Ven
2006-12-20 21:15 ` Stefan Rompf
2006-12-20 14:00 ` Jiri Benc
2006-12-20 18:12 ` Dan Williams
2006-12-21 1:15 ` Matthew Garrett
2006-12-21 1:57 ` Michael Wu
2006-12-21 2:20 ` Matthew Garrett
2006-12-21 3:02 ` Dan Williams
2006-12-21 3:06 ` Dan Williams
2006-12-21 3:14 ` Matthew Garrett
2006-12-21 3:32 ` Dan Williams
2006-12-21 13:19 ` Sven-Haegar Koch
2006-12-21 17:16 ` Dan Williams
2006-12-21 18:27 ` Valdis.Kletnieks
2006-12-22 1:25 ` Matt Domsch
2006-12-20 16:04 ` Maciej W. Rozycki
2006-12-21 5:25 David Brownell
2006-12-21 7:08 ` Stephen Hemminger
2006-12-21 8:11 ` David Brownell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061221011209.GA32625@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).