Refresh ACPI APM and PMU devices on resume

[David Zeuthen]

Hi,

Sorry for not replying earlier,

On Fri, 2006-03-31 at 00:24 +0200, Holger Macht wrote:
> On Do 30. Mär - 20:23:11, Richard Hughes wrote:
> [...]
> > 2006-03-30  Richard Hughes <richard at hughsie.com>
> >  * tools/hal-system-power-hibernate, tools/hal-system-power-suspend:
> > Refresh device types button, battery and ac_adapter on resume, as a
> > suspend or hibernate can do funny things to ACPI. This fixes a common
> > problem where HAL forgets the value of the lid button when it is
> > resuming and may fix other related problems also.
> 
> Well, you can't be sure that this is done after resume! Hal suspend
> scripts support different ways of actually doing the suspend. You do not
> know if the system already finished resume just a few lines later in the
> script.

I think it's a pretty sane decision to assume that the system is resumed
once the helper (e.g. pm-suspend on Fedora, D-BUS calls to powersaved on
SUSE) that the script hal-system-power-suspend invokes.

>  What about other calls to do the suspend other then the pm-scripts
> on fedora core which do not block? On a non-blocking suspend execution,
> it's likely that the device rescan is triggered _before_ the real call to
> /sys/power/state or whatever and hence could cause unexpected
> behaviour. Imagine some related modules are already unloaded when the
> rescan is done...

Then fix whatever helper you use to do this. It's likely a kernel bug if
a script continues execution after writing to /sys/power/state. 

> The best solution IMO would be to let the responsible application/script
> which does the suspend, trigger the rescan if it thinks that this is
> needed. BTW, I never experienced such problems after resume you mentioned.

FWIW, having to rescan stuff (the patch Richard committed above),
unloading and loading modules etc. is a big and nasty hack because
things in the kernel such as ACPI and certain drivers are broken.

Eventually we'll get there.

<rant>
One main point that I seem to be making over and over again these days
is that it's non-sense to put in hacks in upper layers instead of fixing
the fundamental problems. It's pretty bad to do this because it masks
the problems thus only delaying the real fix.
</rant>

Regards,
David