Re: revert yenta free_irq on suspend

[Linus Torvalds]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/