From: Stephen Hemminger <shemminger@osdl.org>
To: David Brownell <david-b@pacbell.net>
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 23:08:47 -0800 [thread overview]
Message-ID: <458A32FF.1010700@osdl.org> (raw)
In-Reply-To: <200612202125.10865.david-b@pacbell.net>
David Brownell wrote:
> 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.
>
The class methods don't work right for that because the physical class
(PCI) gets
called before the virtual class (network devices).
> 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 prev parent reply other threads:[~2006-12-21 7:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-21 5:25 Network drivers that don't suspend on interface down David Brownell
2006-12-21 7:08 ` Stephen Hemminger [this message]
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=458A32FF.1010700@osdl.org \
--to=shemminger@osdl.org \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=netdev@vger.kernel.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).