Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Tue, 24 Feb 2009, Rafael J. Wysocki wrote: >> >> > The only safe way on x86 to shutdown a level triggered ioapic irq >> > outside of irq context is for the driver to program the hardware to >> > not generate an irq. >> >> Well, that changes things quite a bit, because it means we can't change the >> suspend-resume sequence in a way we thought we could without fixing all >> drivers first, but this is exactly what we'd like to avoid by changing the >> core. > > Calling "disable_irq()" is perfectly fine. Agreed, I did not mean to indicate otherwise. > What is not possible on that broken IO-APIC (among other things) is to > actually turn the interrupts off at the apic (ie the whole ->shutdown() > thing). But that's not what we even want to do. What we care about is > just disabling the interrupt from a drievr perspective. > > IOW, the patches I have seen are fine, and all the comments from Eric are > just confusion about what we want done. Largely yes. > WE DO NOT WANT TO TURN OFF THE IO-APIC. That may or may happen later, but > that's totally unrelated to this whole "suspend_device_irq()" thing. Right. The question I was asking is: Can we get the broken cpu hotunplug code out of the suspend path? If we can get the devices into a low power state and not generating interrupts by the time we disable cpus then we do not need to migrate irqs from process context and risk hitting the ioapic bugs. While related safely suspending cpus is a different problem and a different patch. Eric _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
