Hi,
[Added linux-acpi to the CC list, should be there from the start]
On Wednesday, 2 May 2007 16:11, Alexey Starikovskiy wrote:
> Rafael,
>
> > Concluding, it seems to me that the "restore" code path is correct, but the
> > "hibernate" code path is not and should be reworked. Also, it seems th
Hi!
Crazy idea... could we kill hibernate_ops-like struct, and just create
a device for ACPI, using its suspend()/resume()/whatever callbacks to
do the ACPI magic?
> Okay. Since we're trying to separate the hibernation code from the
> suspend code anyway, we can use the opportunity to introduce
Hi,
On Friday, 4 May 2007 00:48, Pavel Machek wrote:
> Hi!
>
> Crazy idea... could we kill hibernate_ops-like struct, and just create
> a device for ACPI, using its suspend()/resume()/whatever callbacks to
> do the ACPI magic?
Hmm, I didn't think about that. It seems to be viable at first sight
On Fri, 2007-05-04 at 00:48 +0200, Pavel Machek wrote:
> Crazy idea... could we kill hibernate_ops-like struct, and just create
> a device for ACPI, using its suspend()/resume()/whatever callbacks to
> do the ACPI magic?
Doesn't that have the ordering problem again? You must ensure that this
sysd
Hi!
> > Crazy idea... could we kill hibernate_ops-like struct, and just create
> > a device for ACPI, using its suspend()/resume()/whatever callbacks to
> > do the ACPI magic?
>
> Doesn't that have the ordering problem again? You must ensure that this
> sysdev is suspended as the last one, and th
Hi,
On Friday, 4 May 2007 14:08, Pavel Machek wrote:
> Hi!
>
> > > Crazy idea... could we kill hibernate_ops-like struct, and just create
> > > a device for ACPI, using its suspend()/resume()/whatever callbacks to
> > > do the ACPI magic?
> >
> > Doesn't that have the ordering problem again? You
