From: Oliver Neukum <oliver@neukum.org>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: linux-kernel@vger.kernel.org,
Patrick Mochel <mochel@digitalimplant.org>,
"Zhu, Yi" <yi.zhu@intel.com>
Subject: Re: suspend/resume support for driver requires an external firmware
Date: Mon, 27 Sep 2004 20:37:48 +0200 [thread overview]
Message-ID: <200409272037.48916.oliver@neukum.org> (raw)
In-Reply-To: <200409271319.05112.dtor_core@ameritech.net>
Am Montag, 27. September 2004 20:19 schrieb Dmitry Torokhov:
> On Monday 27 September 2004 12:19 pm, Oliver Neukum wrote:
> > > Why not just suspend the device first, then enter the system suspend
> > > state; then on resume, resume the device after control has transferred
> > > back to userspace. That way, the driver can load the firmware from the
> >
> > And thus cause errors in all applications wishing to use the network
> > until the firmware is reloaded. It is precisely what cannot be done.
> > The firmware must be present on suspend. The question is, how?
>
> While non-availability might be an issue for other types of hardware I think
> it is ok for network cards. In many cases the interface will have to be
> reconfigured at resume anyway (you move from office to home and the network
> is completely different). Can't resume be handled by virtually removing/
> inserting the device so firmware will be re-loaded as it was just a normal
> startup?
Can suspend/resume be handled as power off/power on?
Taking that to the logical conclusion, there is no suspend/resume.
You suspend in order to preserve the system state. The problem
of mobility is no excuse to improperly implement suspension.
You can't expect something to work suspended which wouldn't work
if the system were powered on.
Regards
Oliver
next prev parent reply other threads:[~2004-09-27 18:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-27 3:43 Zhu, Yi
2004-09-27 7:47 ` Oliver Neukum
2004-09-27 16:50 ` Patrick Mochel
2004-09-27 17:19 ` Oliver Neukum
2004-09-27 18:19 ` Dmitry Torokhov
2004-09-27 18:37 ` Oliver Neukum [this message]
2004-09-27 22:47 ` Denis Vlasenko
2004-09-27 23:06 ` Dmitry Torokhov
2004-09-28 15:07 ` Denis Vlasenko
-- strict thread matches above, loose matches on Subject: below --
2004-09-28 6:16 Zhu, Yi
2004-09-28 6:07 Zhu, Yi
2004-09-28 6:11 ` Patrick Mochel
2004-09-28 5:31 Zhu, Yi
2004-09-28 5:34 ` Patrick Mochel
2004-09-28 2:28 Zhu, Yi
2004-09-28 4:55 ` Patrick Mochel
2004-09-28 2:28 Zhu, Yi
2004-09-28 2:27 Zhu, Yi
2004-09-28 4:52 ` Patrick Mochel
2004-09-27 6:23 Li, Shaohua
2004-09-27 7:51 ` Oliver Neukum
2004-09-27 3:43 Zhu, Yi
2004-09-24 15:03 Zhu, Yi
2004-09-24 11:52 Li, Shaohua
2004-09-24 12:42 ` Oliver Neukum
2004-09-24 6:16 Zhu, Yi
2004-09-24 7:33 ` Patrick Mochel
2004-09-24 8:22 ` Benjamin Herrenschmidt
2004-09-24 16:00 ` Oliver Neukum
2004-09-24 20:11 ` Marcel Holtmann
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=200409272037.48916.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=dtor_core@ameritech.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=yi.zhu@intel.com \
/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
Powered by JetHome