Avoid re-enabling the interrupts in "write_sequnlock_irq" in
cpufreq_timer_notifier() when it gets called in "CPUFREQ_RESUMECHANGE" state
-- that happens if the CPU frequency is detected to be different now from
what it was during suspension, and that's a resume call of a sys device, so
with interrupts off.

Without this patch, it can cause nasty oopses. IIRC resume is done on one
CPU only, so we don't need no lock anyways. Right?

Many thanks to Brian J. Murrell for debugging this issue.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Dave Jones <davej@redhat.com>