On Mon, 1 Aug 2005, Dave Airlie wrote: > > That still doesn't handle the case where a device has an interrupt > handler on a shared IRQ and another device on the chain interrupts it > after it has suspended its device,
I don't know why people bother arguing about this. Face the facts: we have to do things incrementally. Any design that breaks unmodified drivers is by _definition_ broken. You can't fix all drivers, and anybody who starts their arguments with "we should just fix drivers" is living in la-la-land. Anyway. My original PM suggestion handled that case perfectly well. The rule was to make "go to sleep" be a two-phase operation: - phase 1: save state, and possibly return errors - phase 2: turn off where the second stage was done with interrupts disabled and atomically. And the first phase was done without actually changing the state of the device at all (so that if some device said "I can't do that, Dave", there is no need to go back and wake anything up at all), and we could allocate memory freely, because the disk was still working etc etc. For some totally inexplicable reason, the PM people never liked this, and ended up doing a single "power off" setup. Which was always known to be broken, and caused tons of problems, like the fact that save-to-disk had to wake up a device that had already been shut off etc. So the fact that the PM layer was "simplified" to a single-phase setup causes a lot of problems, but hey, stupid is as stupid does. I've given up worrying about what crazy things the PM list comes up with, and instead I now have a hard rule: a patch that breaks some machine gets reverted. Is that too hard to understand? I'll repeat it again: A patch that breaks some machine gets reverted. and maybe somebody on the PM list will one day understand what it means to have slow and steady progress instead of dicking around with the idea of the week. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/