Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: suspend/resume support for driver requires an external firmware
Date: Tue, 28 Sep 2004 14:07:42 +0800
Message-ID: <3ACA40606221794F80A5670F0AF15F8403BD57A2@pdsmsx403>
Thread-Topic: suspend/resume support for driver requires an external firmware
Thread-Index: AcSlHN65Y3tE+Qk0THig+nftOe4sfAABCwtQ
From: "Zhu, Yi" <yi.zhu@intel.com>
To: "Patrick Mochel" <mochel@digitalimplant.org>
Cc: "Dmitry Torokhov" <dtor_core@ameritech.net>,
       <linux-kernel@vger.kernel.org>,
       "Denis Vlasenko" <vda@port.imtp.ilyichevsk.odessa.ua>,
       "Oliver Neukum" <oliver@neukum.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 958
Lines: 27

Patrick Mochel wrote:
> On Tue, 28 Sep 2004, Zhu, Yi wrote:
>> Agreed. I think now we need a clean interface that makes drivers,
>> swsusp or even the end user to work together to finally achieve the
>> goal.
> 
> Well, if you can read firmware back from the device, then
> that interface is called kmalloc() to allocate the buffer,
> and whatever driver-specific routine to copy it from the
> device into that buffer. It then stays in memory during
> suspend and can be rewritten to the device once resumed.
> 
> What's so bad about that?

Hi Patrick,

Do you still think the ->save_state, ->restore_state are the right
approach
or you want the user to provide the firmware to driver before suspend?

Thanks,
-yi
-
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/