From: Dmitry Torokhov <dtor_core@ameritech.net>
To: linux-kernel@vger.kernel.org
Subject: Re: suspend/resume support for driver requires an external firmware
Date: Mon, 27 Sep 2004 13:19:05 -0500
User-Agent: KMail/1.6.2
Cc: Oliver Neukum <oliver@neukum.org>,
       Patrick Mochel <mochel@digitalimplant.org>,
       "Zhu, Yi" <yi.zhu@intel.com>
References: <3ACA40606221794F80A5670F0AF15F8403BD5791@pdsmsx403> <Pine.LNX.4.50.0409270948570.32506-100000@monsoon.he.net> <200409271919.17173.oliver@neukum.org>
In-Reply-To: <200409271919.17173.oliver@neukum.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200409271319.05112.dtor_core@ameritech.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1131
Lines: 23

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?

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/