From: David Brownell <david-b@pacbell.net>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: Network drivers that don't suspend on interface down
Date: Wed, 20 Dec 2006 21:25:10 -0800 [thread overview]
Message-ID: <200612202125.10865.david-b@pacbell.net> (raw)
Hmm, this reminds me of a thread from last summer, following up on
some PM discussions at OLS. Thread "Runtime power management for
network interfaces", at the end of July.
> 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.
The _intent_ of the class suspend() and resume() methods is to let
infrastructure (the network stack was explicitly mentioned!) handle
pretty much everything except putting the hardware in low power
modes ... which last step might, for PCI devices at least, most
naturally be done in suspend_late(). That way it'd be decoupled
cleanly from anything else.
Now, I recently tried refreshing a patch that used those class
suspend() and resume() methods, and for some reason they're not
getting called. I believe they used to get called, although it's
true their parameter wasn't very useful ... it was called with the
underlying device, not the class_device holding state that the
class driver manages.
I just wanted to point out that yes, this ground has been covered
before, with some agreement on that approach. It'd be good to see
it pursued. :)
- Dave
next reply other threads:[~2006-12-21 5:25 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-21 5:25 David Brownell [this message]
2006-12-21 7:08 ` Network drivers that don't suspend on interface down Stephen Hemminger
2006-12-21 8:11 ` David Brownell
[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 ` 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
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
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=200612202125.10865.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.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).