hpet_suspend: reset configuration of all timers

[avg]

Summary

The theory is that SMM code / firmware could be enabling HPET for its
own uses and unexpected interrupts cause a trouble for it. Without this
change my system was unstable after waking up from S3 if HPET was used
as the kernel event timer.

[kib]

Are eventtimers stopped before suspend ? I think it would be useful to pacify the LAPIC timer as well.

[avg]

In D15305#322677, @kib wrote:

Are eventtimers stopped before suspend ? I think it would be useful to pacify the LAPIC timer as well.

It seems that the event timer infrastructure does not participate in the suspend-resume protocol.
I agree that it would make sense to stop and restart timers at the centralized level.

[mav]

Something made me to comment out hpet_disable() call on suspend 8 years ago. Wish I remember what was that.

Also I suspect there may be a little point to disable it here without stopping the eventtimer subsystem from reprogramming it again. May be it should be addressed from the both sides.

[avg]

In D15305#323170, @mav wrote:

Something made me to comment out hpet_disable() call on suspend 8 years ago. Wish I remember what was that.

Maybe the fact that it froze HPET timer(s) and some drivers still needed it...

Also I suspect there may be a little point to disable it here without stopping the eventtimer subsystem from reprogramming it again. May be it should be addressed from the both sides.

This is a very good point. In practice, it seems that the window from stopping HPET to disabling interrupts and stopping other CPUs is sufficiently short. so that HPET does not get reprogrammed.
But that is still possible.
So, after you and Kostik's comments, I think that it's better to explicitly stop and restart event timers.

I've experimented with that and it seems to solve the instability that I had with HPET even without any change to hpet_suspend.
See D15413.

[avg]

Abandoning this change in favor of more general D15413.