Re: Totally broken PCI PM calls

[Linus Torvalds]

On Mon, 11 Oct 2004, Paul Mackerras wrote:
> 
> Maybe the real problem is that we are trying to use the device suspend
> functions for suspend-to-disk, when we don't really want to change the
> device's power state at all.

An acceptable solution is certainly to instead of passing down "go to D3",
just not do anything at all. HOWEVER, I doubt that is actually all that 
good a solution either: devices quite possibly do want to save state 
and/or set wake-on-events. 

But I don't know. Somebody would need to go through the drivers and verify 
that.

NOTE! I don't mind passing down "D3cold" (aka 4 - same as PM_SUSPEND_DISK)  
in theory. The problem is that the very first machine I ever tested it on
clearly didn't like it and refused to suspend. Maybe I was unlucky, but
the point is, the real solution again requires people to _verify_ that.

See the pattern?

Which is why I suggested making it a separate type that is _not_ a normal 
number. Exactly so that you cannot think it's a PCI state by mistake, when 
clearly drivers _do_ think that. And force people to verify it.

You could do it with "sparse" and "bitwise" types too. Sparse will
complain if you use the type in an inappropriate manner. But the basic
issue remains: there are PCI power states, and there are "suspend" power
states, and they are different. And right now people _are_ confused about
them.

Arguing against that is futile. It's a fact.

I'm more than happy to learn that there are other alternatives to solving
the confusion problem. But quite frankly, arguing for undoing the
translation is just stupid. It's putting your head in the sand and saying
"la-la-laa-I-can't-hear-you".

And until something actually tries to sort _out_ the confusion, the state 
translation stays. Does it put devices into sleep modes when you shouldn't 
need to? Sure. But at least it's not confused about things. 

		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/