From: Stephen Hemminger <shemminger@osdl.org>
To: Auke Kok <auke-jan.h.kok@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: General network driver suspend/resume (was e1000 carrier related)
Date: Wed, 8 Nov 2006 13:33:13 -0800 [thread overview]
Message-ID: <20061108133313.20ea5f7c@freekitty> (raw)
In-Reply-To: <455247DA.3090406@intel.com>
On Wed, 08 Nov 2006 13:10:50 -0800
Auke Kok <auke-jan.h.kok@intel.com> wrote:
> Stephen Hemminger wrote:
> > On Wed, 8 Nov 2006 13:04:07 +0100
> > Pavel Machek <pavel@ucw.cz> wrote:
> >
> >> Hi!
> >>
> >>>>> This behavior differs from every other network card, and is also present
> >>>>> in the
> >>>>> 7.3* version of the driver from sourceforge.
> >>>>>
> >>>>> I think the e1000 should try to raise the link during the probe, so that
> >>>>> it
> >>>>> works properly, without having to set ifconfig ethX up first.
> >>>> I think you should cc e1000 maintainers, and perhaps provide a patch....
> >>> I've read it and not come up with an answer due to some other issues at
> >>> hand. E1000 hardware works differently and this has been asked before, but
> >>> the cards itself are in low power state when down. Changing this to bring
> >>> up the link would make the card start to consume lots more power, which
> >>> would automatically suck enormously for anyone using a laptop.
> >> Well, maybe E1000 should behave as the other cards behave, and
> >> different solution needs to be found for power saving? ifconfig eth0
> >> suspend?
> >>
> >> Pavel
> >>
> >>
> >
> > The standard which all network drivers should use is:
> >
> > module insertion:
> > start in initial powerdown state
> >
> > open:
> > power up, bring up link
> >
> > stop:
> > bring down link
> > return to powerdown state unless WOL is set.
> > if doing WOL go to lowest power sensing state
> >
> > suspend:
> > same as stop
> >
> > resume:
> > same as open
> >
> > module removal:
> > stop already called so device should be in power down state.
> >
> >
> > Since suspend is basically same as stop, and resume is open
> > I am going to investigate doing suspend/resume in the network device layer
> > (unless subclassed by driver), so we can rip out the suspend/resume hook
> > from many network drivers. There will still be boards like sky2
> > that need own suspend/resume to deal with dual port etc.
>
>
> beware that e1000 needs to save pci msi config space on top of the normal pci config
> space. Perhaps this needs to be fixed upstream in pci_save_state for msi devices, but
> the api for msi is not capable of detecting this atm.
>
pci_config save needs to save more (including all the pci express stuff).
But until the mmconfig issues are fixed on x86_64 that will be impossible.
Maybe the last fix will solve the problem.
--
Stephen Hemminger <shemminger@osdl.org>
prev parent reply other threads:[~2006-11-08 21:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-06 1:31 e1000/ICH8LAN weirdness - no ethtool link until initially forced up Robin H. Johnson
2006-11-07 7:14 ` Pavel Machek
2006-11-07 15:51 ` Auke Kok
2006-11-07 19:35 ` Theodore Tso
2006-11-08 15:59 ` Auke Kok
2006-11-07 21:31 ` Robin H. Johnson
2006-11-07 22:32 ` Auke Kok
2006-11-08 3:56 ` Robin H. Johnson
2006-11-08 12:04 ` Pavel Machek
2006-11-08 19:54 ` General network driver suspend/resume (was e1000 carrier related) Stephen Hemminger
2006-11-08 21:10 ` Auke Kok
2006-11-08 21:33 ` Stephen Hemminger [this message]
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=20061108133313.20ea5f7c@freekitty \
--to=shemminger@osdl.org \
--cc=auke-jan.h.kok@intel.com \
--cc=linux-kernel@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