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 must ensure that this > > sysdev is suspended as the last one, and that's currently impossible if > > ACPI is modular. > > I do not think acpi has these kinds of ordering requirements... (And I > do not see what it has to do with module or not). Theoretically, ACPI has some ordering requirements. For example, according to the spec, the _PTS system-control method should be executed *after* devices are placed in the appropriate Dx states, which (theoretically) requires us to execute it after device_suspend() (we don't do this in practice, but I think we should). There are some more ordering assumptions like this in the spec and I think we should at least try to follow them or, if that breaks things, document why we don't. That's why I think we should try to do what's needed using hibernation_ops (perhaps we'll need to add a couple of callbacks to hibernation_ops) and then try to replace hibernation_ops with another mechanism allowing us to do the same. We first need to determine which operations have to be carried out at what points so that things don't break. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
