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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |